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Preliminary Announcement and Call for Papers 
USENIX Mach Symposium, Monterey, California 
November 20-22, 1991 


Background 

Mach has become a dynamic addition to the 
operating systems marketplace. DARPA origi¬ 
nally sponsored Mach development, and contin¬ 
ues to emphasize the use and growth of Mach. In 
the larger research community, Mach is ever more 
widely used at many university sites and industrial 
research labs. Versions of Mach have been re¬ 
leased commercially by Encore, NeXT, BBN, and 
mt Xinu. The Open Software Foundation chose 
Mach as the basis for its operating system offer¬ 
ing; now, OSF/1 is finding increasing acceptance 
as computer vendors ready products derived from 
it. 

Recent developments have demonstrated the 
feasibility of Mach 3.0, the combination of a pure 
Mach kernel with single or multiple servers em¬ 
ulating the features of traditional operating sys¬ 
tems. Performance of Mach 3.0 has begun to 
approach or exceed that of Mach 2.5. Workers 
outside of the CMU community have begun to use 
Mach 3.0 as the basis for their projects. In short, 
acceptance of Mach has come about in an aston¬ 
ishingly brief time. 

Activity in this field has been sufficiently wide 
spread that, little more than a year after the first 
usenix Mach workshop, the usenix Association 
is pleased to sponsor an expanded Mach sympo¬ 
sium to bring together researchers, engineers, 
vendors, and users of Mach systems. We will 
encourage discussion of all past and present 
Mach-related research, development, production, 
and applications activities. 

Symposium Overview 

The symposium will be spread over three 
days. The first day will be devoted to two half-day 
tutorials on advanced programming for Mach 3.0. 
The following two days will concentrate on pre¬ 
sentation of refereed papers on current and his¬ 
torical Mach-related work. Long breaks between 
presentations provide ample opportunity for in¬ 
formal discussion. Some time will be available for 
descriptions of work in progress. 


Tutorials 

Richard Draves Writing a Multi-Threaded Mach 
3.0 Server 

David Black Writing an External Memory Man¬ 
ager 

Richard Draves will lead a tutorial analyzing 
the process of writing a multi-threaded server, 
with particular attention paid to the complexities 
of using Mach IPC. During the course of his 
doctoral studies at Carnegie Mellon University, 
Rich rewrote Mach 3.0 IPC to solve problems that 
became apparent with Mach 2.5 servers. 

David Black will demonstrate how to create 
an external memory manager; discussion will cen¬ 
ter on the intricacies of developing an efficient 
(and well-behaved!) external manager. David, 
currently of the Open Software Foundation, re¬ 
ceived his doctorate from Carnegie Mellon for his 
contributions to Mach. 

These tutorials are being developed espe¬ 
cially for this usenix Mach symposium. They will 
explore concepts and rationale as well as real 
examples. They are oriented towards program¬ 
mers who already have some familiarity with us¬ 
ing Mach IPC and VM. Each tutorial is a half-day, 
so conference attendees may take part in both. 
The tutorials will be priced separately from the 
conference registration fee. 

Submissions 

Extended abstracts of 1500-2500 words 
(9000-15000 bytes or 3-5 pages) should be sent 
to Alan Langerman at the address below (those 
submitting hardcopy abstracts must send six cop¬ 
ies). Shorter abstracts run a significant risk of 
rejection as there will be little on which we can 
base an opinion. Preference will be given to those 
submissions that include an outline of the entire 
paper in addition to the extended abstract. Au¬ 
thors must also supply an estimate of the length 
of the full paper. 

A good extended abstract will contain the 
following information in one form or another- 
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:Abstract 100-300 words (half a page) in¬ 
cluded verbatim in the final paper 
Introduction The problem; its importance; pre¬ 
vious work 

Solution Issues, decisions, tradeoffs, ratio¬ 

nale. Implementation details. 
Evaluation Performance results; effort re¬ 
quired; lessons learned. 

Conclusion 

The extended abstract will allow us to ana¬ 
lyze the content of your proposed paper. This 
layout is not cast in concrete; just submit enough 
material to convince the committee that they want 
to accept the paper! 

An outline lists the headings, major points, 
and many minor points for each section of the 
actual paper. The outline gives us an idea of the 
form and style of your paper. 

The submission package should include: 

Your extended abstract 

Outline of rest of paper, if at all possible 

Cover letter, detailing 

• Title of paper 

• Authors 

• Estimate of paper length 

• Contact author (liaison to program com¬ 
mittee) 

• E-mail address and daytime phone num¬ 
ber for contact author 

• Optional home phone number 

• Optional FAX number 

• Surface mail address (required) 

If you are submitting hardcopy, six copies 

are needed. 

The submission should be sent electronically 
to me, alan@encore.com, or by surface mail to 
me at the address listed below. I will not copy and 
re-distribute FAXes, so don’t bother to send 
them. 

All submissions will be acknowledged. Au¬ 
thors of approved abstracts will be required to 
submit full-length papers (8-15 pages) approxi¬ 
mately five weeks after notification of acceptance. 


Areas of interest include, but certainly are 
not limited to: 

• Applications 

• Mach 2.5 and earlier development 

• Mach 3.0 monolithic server 

• Mach 3.0 multi-server 

• Problems with Mach 2.5 / Mach 3.0 features 

• Multiprocessor or parallelization 
experiences 

• Security 

• Performance 

• Productization 

• Experiences with OSF/1 

• Use of Mach subsystems in other operating 
system kernels 

• Comparisons of Mach with other operating 
systems; e.g., Chorus, Sprite, Amoeba, V, 
and of course Unix 

• Porting Mach to off-beat architectures 

• Future work 

Important dates 

Extended abstracts: July 19, 1991 

Notification: August 23, 1991 

Camera-ready, full papers: October 4, 1991 

For further information about the sympo¬ 
sium, contact the program chair: 

Alan Langerman 
Encore Computer Corporation 
257 Cedar Hill Street 
Marlborough, MA 01752 
Voice: (508) 460-0500 
FAX: (508) 485-0709 
E-Mail: alan@encore.com 

Program Committee 

Larry Allen, Open Software Foundation 
Nawaf Bitar, Hewlett-Packard Company 
Susan LoVerso, Encore Computer Corpora¬ 
tion 

Melinda Shore, Cornell University 
Michael Young, Ph.D., Transarc 
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Call for Papers 

Large Installation Systems Administration (LISA) V Conference 
San Diego, California, September 30-October 3, 1991 


Papers are being sought for presentation at 
the Fifth usenix Conference on Large Installation 
Systems Administration, to be held this Fall in 
San Diego, California. A tutorial program will be 
offered in conjunction with the conference on 
September 30. LISA conferences address topics 
of interest to people administering large unix 
sites. Previously, attempts have been made to 
define “large” in terms of number of machines, 
gigabytes of disk, or users. 

We feel that it is more fruitful to define a 
large installation as one that has problems that 
cannot be solved by simply scaling up well- 
understood solutions used on single machines 
with few users. We are particularly interested in 
papers which take a theoretical or comparative 
attitude, presenting discussions of the relative 
merits of various approaches to problems. As 
always, we welcome presentation of specific so¬ 
lutions to specific problems, where they advance 
the state of the art. We also welcome papers 
discussing “non-technical” problems dealing with 
users and management. 

Topics of interest include but are not limited 
to: 

• Strategies for managing data - file migra¬ 
tion, archive systems, backup systems 

• Security issues, especially where multiple 
people are privileged users 

• Human issues of administration 

• Integration of heterogeneous systems 

• Usage monitoring and accounting systems 

• Administration of remote sites 

• Network monitoring 

• Queuing systems 


Papers should be from 5 to 15 pages in 
length, including diagrams, figures, etc. Complete 
submissions are due by July 8, 1991. The com¬ 
mittee will consider and comment on extended 
abstracts or outlines submitted by June 17th, but 
may require full papers to be submitted before a 
final decision is made. 

Extended abstracts or outline deadline: 6/17/91 
Submission deadline: 7/8/91 
Authors notified: 7/29/91 

Program committee: 

Steve Romig, Ohio State University 
Bjorn Satdeva, /sys/admin Inc. 

Steve Simmons, Industrial Technology Inst. 
Pat Wilson, Dartmouth University 

For more information, please contact the 
program chair: 

Elizabeth D. Zwicky 
SRI International 
333 Ravenswood Ave. 

Menlo Park, CA 94025 
zwicky @erg. sri. com 
415-859-3290 

(9 A.M. to 6 P.M. Pacific time) 
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Call for Papers 

USENIX Winter 1992 Technical Conference 

San Francisco Hilton, San Francisco, California, January 20-24, 1992 


Tutorial Program 

Monday and Tuesday, January 20-21 

Refereed Papers and Invited Talks 

Wednesday through Friday, January 22-24 

Some believe that UNIX standardization ef¬ 
forts have killed innovation. And yet, we need 
innovation, and opportunity for it abounds. 

Large write-once disks make the current file¬ 
system untenable. Even the 2 gigabyte file limit 
built in all through the system breaks. Gigabit 
networking clogs an I/O model designed to push 
hundreds of kilobytes per second, not hundreds of 
megabytes. System administration for thousands 
of machines? Programming tools for distributed 
workgroups? Object-oriented and visual pro¬ 
gramming? Microkernels with client/server archi¬ 
tectures? RAID disk arrays? Transcontinental file 
servers? What’s a programmer to do? 

The USENIX Winter 1992 Conference solicits 
new work on all topics related to UNIX or UNIX- 
inspired systems programming and technology. 
But as always, we care most about innovation and 
how it coexists with (and sometimes thrives on) 
stasis. 

Please target a sophisticated technical audi¬ 
ence, particularly knowledgeable of operating sys¬ 
tem issues and keenly interested in new and ex¬ 
citing projects in many areas. Vendors are 
encouraged to submit technical presentations on 
products. However, we will reject obvious prod¬ 
uct announcements. Previously published papers 
will also be rejected, although “retrospective” 
papers may describe work done years ago. 

Submissions must be in the form of extended 
abstracts, 1500-2500 words in length (9000-15000 
bytes or 3-5 pages). Shorter abstracts will not give 
the program committee enough information to 
judge your work fairly and, in most cases, this 
means your paper will be rejected. Longer ab¬ 
stracts and full papers simply cannot be read by 
the committee in the time available. However, 


you may append a full paper to an extended ab¬ 
stract; this is sometimes useful during evaluation. 

The extended abstract should represent your 
paper in “short form.” The committee will want 
to see that you have a real project, that you are 
familiar with other work in your area (i.e., include 
references), and that you can clearly explain your¬ 
self. Please, this is not a mystery to be solved: you 
should have results and they should be summa¬ 
rized in your abstract. A good submission will 
contain: 

Abstract 

• The abstract should be included verbatim in 
the final paper. 

Introduction 

• Introduce the problem: why is it important? 

• Reference previous work. 

How We Solved the Problem 

• More details on the problem and its issues. 

• Design decisions and tradeoffs, and why 
they were made. 

• Implementation details. 

Evaluation 

• Data on performance and effort required. 

• How well does it work? 

• What would you do differently? 

• If it failed, why? 

• What did you learn from it? 

Conclusion 

• Summarize the paper, emphasizing why it 
is important and what was learned. 

In addition to the extended abstract, every 
submission should include: 

• A clearly designated contact author who 
will be your link to the program committee. 

• A daytime phone number (essential!). 

• A surface mail address (required). 

• An email address, if available; email is by 
far our best path of communication. 

• A home phone number (optional, although 
questions often arise on evenings and week¬ 
ends and it will avoid delays). 
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• A FAX number (optional). 

• Any special audio/visual equipment you 
may require. A microphone, overhead pro¬ 
jector, and 35mm projector will be pro¬ 
vided as standard equipment. We are happy 
to provide additional assistance and equip¬ 
ment to make your presentation as audio 
and visually appealing as possible. 

• Indication of student status 

Presentations are usually scheduled for 25 
minutes. 

The final date for submissions is August 19. 
Authors of accepted submissions will be notified 
by October 1. They will immediately receive in¬ 
structions for the preparation of camera ready 
final papers to be published in the conference 
proceedings. Camera-ready papers of 8-12 type¬ 
set pages will be due by November 22. 

Submissions can be sent (in order of com¬ 
mittee preference): 

via email to: SFusenix@usenix. org or 

uunet! usenix! SFusenix 

via paper to: 

Eric Allman 

Computer Science Division, EECS 

University of California 

Berkeley, CA 94720 

via FAX to: (415) 843-9461 

Awards for Best Papers 

A cash prize for the best paper by a full-time 
student will be awarded by the conference pro¬ 
gram committee. With your submission, please 
indicate if you are a full- time student. 


An award for Best Paper at the conference 
is also made by the committee. 

TECHNICAL PROGRAM COMMITTEE 

Chair: Eric Allman, University of California, 
Berkeley 

Rick Adams, UUNET Technologies , Inc . 
Andrew Birrell, Digital Equipment 
Corporation, Systems Research Center 
Tom Ferrin, University of California , 

San Francisco 

Bob Gray, US West Advanced Technologies 
Teus Hagen, OCE 
Steve Johnson, Athenix 
Pat Parseghian, AT&T Bell Laboratories 
Dennis Ritchie, AT&T Bell Laboratories 
Greg Rose, IBM Thomas J. Watson 
Research Center 

David Rosenthal, Sun Microsystems 
Brent Welch, Xerox PARC 

RELEVANT DATES 

Abstracts Due 
Monday, August 19 
Notification to Authors 
Tuesday, October 1 
Camera-ready Papers Due 
Friday, November 22 

Materials containing all details of the tech¬ 
nical and tutorial program, conference registra¬ 
tion, hotel and airline reservation information will 
be mailed in October 1991. Contact the usenix 
Conference office. 
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Call for Tutorial Proposals 

In an effort to continue to provide the best 
possible tutorials to its membership, the Associ¬ 
ation is soliciting proposals for future new tuto¬ 
rials. The proposals can cover any subject, rang¬ 
ing from introductory to advanced materials, 
although one should avoid overly introductory 
materials. Previous conferences have included tu¬ 
torials on such diverse topics as UNIX Network 
Programming, X Toolkit Intrinsics, Topics in Sys¬ 
tem Administration, Multimedia and Hyperme¬ 
dia, System V and Berkeley Kernel Internals, and 
Software Contracts and Intellectual Property, 
among many others. 

Tutorials usually run for a full day (6 hours 
of class time plus morning, lunch, and afternoon 
breaks), although we are currently experimenting 
with half day (3 hour) tutorials. A proposal should 
include a statement of what you want to teach, 
and a coherent outline of your tutorial (not simply 
a list of what you want to cover, but the order in 
which you want to cover it, with an estimate on 
the amount of time for each subject). Because a 
tutorial lasts on the order of 6 hours, we need to 
know that you can comfortably fill that time, but 
not overfill it (i.e., that you won’t suddenly dis¬ 
cover at 4:30 that you have another 3 hours of 
slides left to present). If you have any supple¬ 
mentary materials to distribute (e.g., copies of 
papers, shell scripts, source code, illustrations, 
etc.), give an indication of the volume of supple¬ 
mentary material, and a rough count of the num¬ 
ber of slides you will be presenting during class. 
(Historically, a typical tutorial has between 
75-200 slides, along with up to 200 pages of sup¬ 
plementary material). If possible, include a cou¬ 
ple of sample slides (one with text, one with a 
graphic) with your proposal. If you have a com¬ 
plete or draft course already done, a copy of the 
current materials would be most useful. 

We also need to know if you will be pre¬ 
senting or distributing any source code. If so, is 


it copyrighted by someone other than you? If you 
do not hold the copyright, you must be able to 
demonstrate that you have permission to use this 
material (this may be dealt with by requiring 
course attendees to have a source license). Be¬ 
cause the usenix tutorials fall outside of the “fair 
use” clause of the U.S. copyright code, the same 
rules apply for supplementary papers or reports. 

Your proposal should also include a summary 
of your previous teaching or lecturing experience, 
as well as several references (that is, one or two 
people who have seen you teach). These may be 
your students, supervisors, or colleagues. 

Remember, this is just a proposal, so nothing 
you submit will be cast in concrete. You may later 
decide to change some ordering of materials, or 
we may suggest some changes. You needn’t worry 
about getting it perfect the first time around. 
What we are trying to do is get a very solid feel 
for what you are offering. 

The tutorial schedule is currently filled for 
the Summer 1991 conference in Nashville, so all 
proposals will be for the Winter 1992 conference 
in San Francisco, and for all conferences after 
that. The tutorial schedule for San Francisco is 
almost finalized, so proposals should arrive as 
soon as possible. The deadline for proposals for 
the Summer 1992 conference is December 17, 
1991. Please send your proposals to 
dvk@usenix.org, or by physical mail to: 

Daniel Klein 

usenix Tutorial Coordinator 

5606 Northumberland 

Pittsburgh, PA 15217-1238 

Be sure to include your physical and e-mail 
address, along with your telephone number. 
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Calendar of UNIX Events + 


1991 Jun 17-19 

Sun User Group 

1991 Jun 20 

IEEE Standards Board 

1991 Jul 8-12 

TCOS 

1991 Jul 10-11 

JUS Symposium 

1991 Jul 15-17 

UKUUG 

1991 Aug 5-8 

Interex 

1991 Aug 13-15 

UniForum Tutorials 

1991 Sept 10-12 

European Sun 

1991 Sept 16-20 

EurOpen 

1991 Sept 24-27 

AUUG 

1991 Sept 26 

IEEE Standards Board 

1991 Sept 30-Oct 3 

Large Installation Sys. Admin. V 

1991 Oct 7-11 

Interop 

1991 Oct 10-11 

Multi-User 

1991 Oct 21-25 

TCOS 

1991 Oct 30 

IEEE CS SCC/SAB 

1991 Oct 3-Nov 1 

UNIX EXPO 

1991 Oct 31 

Sun User Group 

1991 Nov 4-8 

ISO/IEC JTC1 SC22 WG15 

1991 Nov 14 

APP/OSE Users Forum 

1991 Nov 14-15 

JUS Symposium 

1991 Dec 

UKUUG 

1991 Dec 3-4 

JUS UNIX Fair ’91 

1991 Dec 5 

IEEE Standards Board 

1991 Dec 7-10 

Sun User Group 

1991 Dec 9-13 

DECUS 

1992 Jan 20-24 

UniForum 

1992 Jan 20-24 

USENIX 

1992 Mar 11-18 

CeBIT 92 

1992 Apr 6-9 

EurOpen 

1992 Apr 6-10 

TCOS 

1992 May 4-8 

DECUS 

1992 Jun 2-4 

UNIX EXPO West 

1992 Jun 8-12 

USENIX 

1992 Jun 22-24 

Sun User Group 

1992 Sept 8-11 

AUUG 

1992 Oct 6 

ISO/IEC JTC1 SC22 WG15 

1992 Oct 26-30 

Interop 

1992 Nov 23-27 

EurOpen 

1992 Dec 

UKUUG 

1993 Jan 25-29 

USENIX 

1993 Mar 15-18 

UniForum 

1993 Mar 24-31 

CeBIT 93 

1993 Jun 21-25 

USENIX 

1994 Jan 17-21 

USENIX 

1994 Mar 23-25 

UniForum 

1994 Jun 6-10 

USENIX 

1995 Jan 16-20 

USENIX 

1995 Feb 20-24 

UniForum 

1995 Jun 19-22 

USENIX 


Atlanta, GA 
New York, NY 
Santa Clara, CA 
Tokyo, Japan 
Liverpool, UK 
San Diego, CA 
Washington, D.C. 

Birmingham, UK 
Budapest, Hungary 
Sydney, Australia 
New York, NY 
USENIX San Diego, CA 
San Jose, CA 

UniForum Canada, Montreal 
Parsippany, NJ 
Nashville, TN 
NY, NY 

Amsterdam, Netherlands 
Stockholm, Sweden 
NIST, Gaithersburg, MD 
Osaka, Japan 
Edinburgh, UK 
Tokyo, Japan 
New York, NY 
San Jose, CA 
Anaheim, CA 
San Francisco, CA 
San Francisco, CA 
Hannover, Germany 
Jersey, UK 
Atlanta, GA 
Atlanta, GA, 

Anaheim, CA 
San Antonio, TX 
Washington, DC 

World Congress C, Melbourne, Australia 
Denmark 

San Francisco, CA 
Utrecht, Netherlands 
Manchester, UK 
San Diego, CA 
San Francisco, CA 
Hannover, Germany 
Cincinnati, OH 
San Francisco, CA 
Dallas, TX 
Boston, MA 
New Orleans, LA 
Dallas, TX 
San Francisco, CA 


+ Compiled with the assistance of Susanne Wilhelm of Windsound Consulting. 
*USENIX workshops, symposia, and mini-conferences 
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Book Review 
PROGRAMMING IN PERL 
by Larry Wall and Randal Schwartz 

(O’Reilly & Associates, 1990, ISBN 0-937175-64-1, $24.95, 454 pages) 

Reviewed by Tom Christiansen and Rob Kolstad 


The O’Reilly folks have released another 
Nutshell Handbook, this time on the perl pro¬ 
gramming language. Perl is the most significant 
general-purpose tool to hit the UNIX world in 
years, filling a niche between shell programming 
and C programming. We hope and believe it will 
soon become a standard utility (like awk and sect). 

If you haven’t used perl , it’s a lot like C with 
awk , sed, grep , shell programming, and just about 
everything else included. The magnitude and 
quality of the synergy is surprising. Problems dif¬ 
ficult or impractical to code in shell scripts are 
often much easier to write and faster to run when 
transcribed into perl. The language has been de¬ 
scribed as a shell for C programmers, a basic for 
UNIX, and even an apl on LSD. Because perl is 
interpreted, incremental development and testing 
is simple. Its powerful constructs combine with 
efficient execution to yield a pleasant program¬ 
ming environment. 

Another brainchild of Larry Wall (who gave 
the world patch and m), perl has enjoyed ever 
increasing popularity in the UNIX community 
since its initial public release about four years ago. 
In particular, system administrators have found it 
handy, since they’re the ones most often tasked 
with writing or maintaining convoluted shell 
scripts. Some test and manufacturing groups at 
computer vendors are now considering using perl 
as their one-and-only language for test engineers. 

The perl language is available without cost 
from various ftp sites on the Internet. It’s also on 
the GNU tape distributed by the Free Software 
Foundation, although it isn’t GNUware per se. 
Friends of perl distribute it on request to their 
less-connected neighbors. While few formal cor¬ 
porate entities yet back perl , its quality is typical 
of Larry Wall productions. Support comes quickly 
from the comp.lang.perl newsgroup (or electronic 
mail to any of the USENET perl gurus). Most ques¬ 


tions regarding perl resemble “how do I do this” 
rather than “this appears to be a bug”. 

Until now, perl programmers have had to 
make do with the meandering, 75-page man 
‘page’, a bit intimidating for people just trying to 
get a handle on the language. For this reason, if 
no other, this book by Larry Wall and Randal 
Schwartz is welcome. 

The book is hefty (1.1 inches thick; 6x9 inch 
format) with 450 pages of densely packed mate¬ 
rial. It is organized into seven chapters, starting 
with ‘An Overview of Perl,’ which explains the 
basic concepts of perl in a fairly informal fashion. 
The phrase ‘informal’ is probably an understate¬ 
ment; this is definitely not a dry and stuffy tech¬ 
nical book. Like the man page (once described as 
more of an editorial than a reference guide), the 
book tries to entertain you as it teaches. Whether 
it actually succeeds at this depends on your par¬ 
ticular sense of humor. 

The second chapter, ‘Practical Program¬ 
ming,’ is also easy to read. The authors show the 
kinds of problems perl is good at solving and ways 
to use perl to solve them. It begins with a typo¬ 
laden excerpt from the Book of Job and then uses 
the theme of text manipulation and repair 
throughout the chapter. This is probably the best 
chapter in the book for two reasons: it gives you 
the material at a nice even pace and because the 
humor seems to work well here. 

Chapter 3, ‘The Gory Details,’ gives just 
that. This is for the language lawyers in your shop, 
the ones who want to know all the ins and outs 
of a language (of which there are quite a few in 
perl) before they start programming in it. It in¬ 
cludes sections on data types, operators, control 
structures, subroutines, regular expressions, for¬ 
mats (remember Cobol pictures?), special vari¬ 
ables, and packages. 
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Chapter 4, ‘Functions,’ describes all the 
built-in functions in perl (over 125 of them). This 
includes quite a lot of the C library, which makes 
it somewhat lengthy (over 75 pages). Reading this 
section can improve your fluency in UNIX as well 
as in perl . 

Chapter 5, ‘Common Tasks in Perl,’ is some¬ 
thing of an odd chapter. It is like a cookbook full 
of recipes for things the authors think readers will 
want to do. It is a tutorial by example that dem¬ 
onstrates the power and style that perl can 
achieve. Some examples include: computing the 
difference or intersection of two arrays, squeezing 
out multiple blank lines, exception handling, and 
putting commas into numbers. These tasks vary 
quite bit; some seem a bit too specific to be useful. 
They are uniformly interesting, however, for their 
brevity. 

Chapter 6, ‘Real Perl Programs,’ consists of 
program listings for an assortment of different 
kinds of full-blown programs. Subheadings in¬ 
clude database manipulation, grep programs, pro¬ 
gramming aids, text manipulation tools, interpro¬ 
cess communication (perl includes access to 
sockets), and system administration programs. 
The programs are pretty readable (as perl pro¬ 
grams go), but one of them extends for three 
pages of code with nary a comment. 

The longest of the Chapter 6 programs is a 
rewrite of the passwd program in perl. The new 
version performs much more extensive checking 
than the one that is delivered with your system is 
likely to do. 

Chapter 7, ‘Other Oddments,’ seems to be all 
the miscellany that didn’t fit in one of the other 
major chapters. The command line flags are ex¬ 
plained, commons goofs for novices are pointed 
out, the perl debugger and libraries are over- 
viewed, tips for optimization are given, the 
security-analyzing features of taintperl are ex¬ 
plained, and there’s even a section on perl poetry. 

Appendix A contains a BNF-like syntax 
grammar for perl . Appendix B outlines the perl 
library, which includes a number of useful func¬ 
tions. 


The glossary at the end defines a lot of tech¬ 
nical terms pertaining to perl , programming lan¬ 
guages, and UNIX in general. The Three Principal 
Virtues of a programmer (according to Wall) are 
laid out: laziness, impatience, and hubris. Most of 
the entries are funny; some of them perhaps a 
little too much so, but it’s still fun to read. 

The 20-page index works well if you know the 
precise name of the topic you are seeking. How¬ 
ever, if you’re looking for help and hints, it is not 
quite as useful (e.g., if you want to convert from 
the UNIX system’s seconds-since-1970 date to a 
human readable one, you must know ctime is the 
answer before you can find it). 

Whether you can actually learn perl from this 
book is unclear. It depends upon your back¬ 
ground: if you know UNIX shell programming al¬ 
ready, perl will probably be easy. If you know C 
in a Unix environment, it’ll be even easier, but 
the differences between perl and C may annoy 
you. On the other hand, if you are neither a sed 
nor awk wizard and C programming is a black art 
to you, then this book probably isn’t going to help 
you much. The more you know about UNIX to 
start with, the faster perl will make sense to you, 
and vice versa. Unfortunately, if you’re still a 
UNIX novice, it’ll be a lot harder for you, because 
the book assumes that you know about block 
structure (i.e., C’s and awk' s braces), regular ex¬ 
pressions, and the style of UNIX system calls. 

Nonetheless, as the only book on perl avail¬ 
able, and because it was co-written by the lan¬ 
guage’s author, it is the definitive reference on the 
language and essential reading for anyone want¬ 
ing to program in perl . 

Tom Christiansen is a software development engi¬ 
neer at Convex Computer Corp. Tom also teaches a 
USENIX tutorial on programming in perl. Rob Kolstad 
is software manager at Sun Microsystems in Colorado 
Springs, gives numerous tutorials on systems adminis¬ 
tration, and serves as Secretary of the USENIX Board of 
Directors . 
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Standards Liaison 

M. Kirk McKusick , President , USENIX 

John S. Quarterman established the position 
of USENIX Institutional Representative (IR) to 
TCOS and served in that role from 1985 to 1990. 
By having an IR, usenix has given a voice to 
concerned individuals who cannot participate di¬ 
rectly in the standards process themselves. In a 
field fraught with large vendor pressures, John 
sought to exploit usenix’s vendor-neutral posi¬ 
tion to provide a unique perspective in the stan¬ 
dards community. He developed usenix’s pres¬ 
ence over time with considerable effort. John was 
the driving force behind the October 1987 posix 
Portability Workshop. 

John defined the role of the usenix repre¬ 
sentative as having two basic responsibilities. 
First, to be an informed participant representing 
the usenix membership in the tcos activities. 
This meant that he attended meetings, read the 
mailings, and discussed and solicited input about 
the activities from technical experts and the mem¬ 
bership. 

The second task is to feed information about 
the tcos activities back to the membership. 
Through the snitch reports that John initiated and 
nurtured, he has provided critical information to 
interested individuals worldwide. 

Through his direct lobbying and balloting 
work, John helped guard the quality of UNIX for 
its members. As a standard is being written, it is 
possible to influence it, to correct its mistakes, its 
omissions, and its design decisions. After adop¬ 
tion, such corrections are harder, sometimes im¬ 


possible. Since most members al-ready find them¬ 
selves using standardized systems, John sought to 
ensure that the standards are ones we can live 
with, not just suffer under. As an example of this 
work, John coordinated the writing of a white 
paper for the systems administration committee 
(1003.7) to keep them from preventing innovation 
in administering a network of computers by bas¬ 
ing the standard on a single machine model. 

John managed to spread the influence of the 
IR beyond the US boundaries through his formal 
and informal liaising with other groups. He ini¬ 
tiated the joint funding by EurOpen and USENIX 
for a person to report on the standards work being 
pursued in Europe and at the international bodies 
such as ISO WG15. 

The Association — and the UNIX world in 
general — are greatly indebted to John for the 
pioneering work that he did in defining and es¬ 
tablishing usenix’s role in the standards process. 
He raised the profile of standards within the As¬ 
sociation to a point where 85% of the members 
recently surveyed consider standards activities an 
important part of the work of usenix. He was 
influential in convincing some groups in the com¬ 
munity that standards efforts are worthwhile and 
that they should be involved in the process, posix 
is much better for that. Throughout most of his 
tenure John was an unpaid volunteer; he put in 
more hours of volunteer work than most people 
commit in a lifetime. His energy and efforts will 
be sorely missed. 


12 


May/June 1991 



;login: 16:3 


Torch Passing 

Peter Collinson 
USENIX Standards Liaison 

The end of an era in snitch reporting is at 
hand. Jeff Haemer is laying aside his quill as 
usenix Standards Watchdog report editor and is 
taking on a more paternal role for a time. He was 
tired of three small girls inquiring who the 
stranger was at the dinner table. 

Jeff has edited the Standards Watchdog re¬ 
ports for two years now. As many snitches know 
from personal experience he was an extremely 
‘gentle’ editor, he helped them to make the re¬ 
ports say what was meant rather than what had 
been originally written. His editorials on stan¬ 
dards were always well tempered and insightful, 
pulling together the varied threads of snitch re¬ 
ports and presenting the information as a more 
coherent picture. 

Jeff was responsible for building the usenix 
Standards Watchdog Committee into an influen¬ 
tial, bustling, nationally-recognized organization. 
The reports in this newsletter are undoubtedly 
popular inside the Standards community and out. 
We have Jeff to thank for pushing things in this 
direction, in finding snitches and making their 
reports available to the wider audience. 

To do this, he used his vacation. There are 
four weeks of IEEE posix standards meetings ev¬ 
ery year. Think about it a little, folks. 


Jeff was properly thanked by his friends and 
snitches at the Snitch dinner during the recent 
IEEE posix working group. USENIX thanks Jeff for 
all the hard work and time he has given as editor, 
and wishes him well in his endeavours. I person¬ 
ally would like to thank Jeff very publically for all 
the help he has given me during our short ac¬ 
quaintance. 

We welcome Stephe Walli in Jeffs place. 
Stephe has just attended his sixth ieee posix 
meeting; his first as snitch editor. He seemed to 
spend most of his time writing names down, so we 
expect some good reports here and on the net¬ 
work. I also managed to twist his arm to help me 
write many of the paragraphs above. 

We would both welcome suggestions and 
ideas about how to present the snitch information. 
Stephe’s email address is: speakeristephe 
@mks. com or uunet! watmath! mks! speaker- 
istephe. Mine is: pc@hillside.co.uk, if in doubt 
fire this first at uunet. 
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An Update on UNIX-Related Standards Activities 

Jeffrey S. Haemer 

Report Editor, USENIX Standards Watchdog Committee 


ANSI X3B11.1: WORM File Systems 

Andrew Hume <andrew@research.att.com> 
reports on the January 22-24, 1991 meeting in 
Murray Hill, NJ: 

Introduction 

X 3 BH .1 is working on a standard for file in¬ 
terchange on write-once media (both sequential 
and non-sequential, i.e., random access): a por¬ 
table file system for worms. First let me apologize 
for laggardly snitching; we have had an extra 
meeting (in December) to accelerate our progress 
with the draft proposal, and I have been busy 
writing a programmer’s guide to the draft pro¬ 
posal. I shall describe the results of the last three 
meetings, October (Nashua, NH), December 
(Murray Hill, NJ), and January (San Jose, CA), 
not in chronological order, but rather as a sum¬ 
mary of where we are now. Although many de¬ 
tails remain to be ironed out, we have broad 
agreement on the current proposal. 

Multi-volume file systems 

The draft proposal supports multi-volume file 
systems. To avoid the confusion that reigned at 
our meetings, I will define what this means. A 
volume is a logical address space (on some me¬ 
dium). Thus, a typical WORM disk is two volumes, 
as each side is addressed separately. A volume 
partition is simply a contiguous subset of a vol¬ 
ume’s address space. A logical volume is simply 
a set of (volume) partitions upon which a file 
system is recorded. Finally, a logical volume set is 
a set of volumes with a single volume set iden¬ 
tifier. (That is, it is simply a publishing concept.) 
Note, however, that when I say file system, I 
mean a set of files and directories described by 
possibly multiple directory hierarchies (typically 
each would be in a different character set). The 
(logical) block size, not the physical sector size, 
is 2' bytes, 9</<65536, and implementations 
would have to support at least a block size of 
64kb. The various size limits are generous; in¬ 


ternal block addresses allow 64K volumes, 64K 
partitions per volume, and 2 32 blocks per parti¬ 
tion. 

Volume Headers 

The location of the volume header (the an¬ 
alog of the superblock) is a tricky issue because 
of the requirement that systems be able to boot 
off a disk in our format and there is simply no 
consensus on the size or location of the boot area. 
Accordingly, pointers to the volume header (ac¬ 
tually a sequence of various descriptor records) 
are recorded at one or more of 0, 16, 64, 128,192, 
256, N -16, N - 4 (where N is the size of the disk). 
The seek speed (or rather the lack of seek speed) 
of WORM disks encouraged us to put these at both 
ends of the disk. The volume header record, like 
all the other major control structures, has a 16-bit 
CRC and a unique 8 -byte tag, which should pre¬ 
vent misrecognition. 

Volume/Partition Structure 

The volume layer handles space allocation 
for the volume, definitions of partitions, and bad- 
block mapping. The partition layer does its own 
space allocation, supports the file system, and 
does partition-access logging. Partitions have file¬ 
system-type tags; the intent is to allow partition 
w to be an X3B11.1 file system, partition x to be 
a CDROM file system, partition y to be an MS-DOS 
floppy file system, and partition z to be of un¬ 
known type. There should be a registry for this 
type field; vendors may want to register their 
file-system formats. 

Bad-Block Handling 

A simple defect-management scheme has 
been adopted; it is similar to the bad-block 
remapping scheme used for most smd disks. 
There was considerable resistance to such a 
scheme, particularly from the representatives of 
the hardware vendors, as the (scsi) worm disks 
already do as much error detection/correction as 
is possible. However, defect management (above 
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the disk driver level) is still necessary because: 1. 
error correction/detection in the drive can be, and 
for performance reasons often is, turned off, 2. 
errors can easily occur between the disk and the 
host’s main memory (have you ever heard of DMA 
or bus errors?), and 3. even though SCSI disks 
present an “error free” interface, most drives 
have a limited number of errors they can cope 
with, and many early drives did little or no error 
correction. 

FCB Format 

As you may recall, multiple versions of the 
direct entry (the equivalent of the inode) are 
stored in a data structure called the file control 
block (fcb). The original proposal involved var¬ 
ious levels of indirect blocks exactly like classic 
UNIX file systems. We adopted my proposal 
(adapted from an observation by Dennis Ritchie) 
for a simpler, more general format that allows 
arbitrary structures, which can be specialized for 
different applications. 

Partition Access Records 

This is more like logging changes to the file 
system than a security thing like access control 
lists. The idea is to have periods of writing to the 
partition bracketed by specific control records so 
that it will be possible to tell if a system closed out 
that partition gracefully. (More bluntly, did we 
unmount the partition gracefully or did the system 
crash in the middle of a session?) These records 
are kept on a per-file-system basis and are re¬ 
corded as variants of direct entries in a structure 
identical to fobs. Another side issue is support for 
a so called “stable” record, which is analogous to 
the proposed stable sync feature of BSD Unix. 
(The control structures such as inodes and indirect 
blocks are written to disk, but the user’s data may 
not be, yet.) This peculiar state avoids the need 
to run fsck (or its equivalent) on the disk but you 
still have to get the user’s data from somewhere. 
[Ed: does anyone really need this “stable” state?] 

Recording Directories 

For performance reasons, it is proposed that 
directories, or rather the records (fids) identify¬ 
ing the files (and subdirectories) in that directory, 
be kept in optionally sorted order. This would be 
in binary and not lexicographic order (thus evad¬ 


ing nettlesome character-set-collating-order is¬ 
sues). It is not trivial to support this but is prob¬ 
ably worth it. Related to this is the issue of system 
areas in directories and fids. It is expected that 
these areas will contain accelerator structures, 
such as B-tree indices and so on. Here and else¬ 
where in the standard, the governing principle is 
to allow systems to use such structures, but to 
neither mandate nor standardize their use. 

Anonymous Files 

There are numerous fcbs, or file-like objects, 
that have no fid. An example might be a Ma¬ 
cintosh resource fork. The question is whether to 
make these visible to the user. This is a serious 
issue, and one not confined to this standard. It is 
an issue for the system supporting access to the 
file system on the disk. Do we rely on this system 
to do the right thing or should we mandate a 
mechanism? For example, take the example of a 
Macintosh file (with its resource fork) on a system 
(say Unix) that doesn’t have that concept. We can 
either trust that the vendor supplying your Unix 
has implemented an fcntl (or ioctl ) to access the 
resource fork, or we can evade the issue com¬ 
pletely by mandating that the resource fork be 
available for normal access by a reserved name 
such as foo.RFORK. The general feeling is that 
users will not allow a standard to reserve parts of 
the file name space for its own use. Thus, it seems 
likely that access would have to be via standard¬ 
ized fcntl calls, but these are outside the scope of 
our standard. 

Byte Order 

I have pressed the issue of the byte order for 
numeric fields. The previous notion was to allow 
the recording system to choose the byte order. 
The issue is not technical (everyone seems happy 
to pick just one and stick with it) but political. We 
picked lsb order: the order used by the low-end 
(and slowest) systems. We measured the perfor¬ 
mance degradation for low-end MSB systems (the 
slowest Macintosh we could find), and the CPU 
cost of straightforward C code. Interpreting the 
byte order for the worst case (a block of integer 
block numbers) was about 10ms — comparable to 
doing a single disk i/o and one or two orders of 
magnitude less than the cost of doing a disk seek. 
(Careful assembly code would be much faster 
than this.) 
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Extended Attributes 


International Activity 


The direct entry for a file has many attributes 
or fields. Some of these will be faster to access and 
be stored directly in the direct entry. The rest will 
be stored in an extended attribute record area 
much like resources in a Macintosh resource fork. 
There are two issues: which attributes get faster 
access and how do you access the other attributes? 
The former is something the standard specifies; 
our guiding principle was to include the fields 
needed for a UNIX stat or an ms-dos (or vms) dir 
command. Unfortunately, the issue of access is 
beyond the domain of our standard and needs to 
be addressed by posix, probably best by 1003.8. 
Internally within our standard, the extended at¬ 
tributes are identified by a 32-bit number, some 
of which are set in the standard and the rest by 
a registry maintained by some authority (like 
ansi). The current list of extended attributes is 
given below. Treat it as very preliminary and 
subject to change. 


information creation 
information 
modification 
information expiration 
information effective 
file creation 
file access 

file modification 
file backup 

file expiration 
file attribute 
file effective 


file abstract 
file type 

associated file 
data compression 
protection 

application-specific data 
segment 

implementation segment 
escape sequences 
segment 
action history 
icon 

environment type 


Character Sets 

We have adopted a somewhat simpler way of 
dealing with character sets than the cd-rom stan¬ 
dard (iso 9660). The current schemes available 
are 


0 

0-9A-Z_. from Latin-1 (ISO 8859-1), 

1 

portable filename character set 0-9A-Za- 


z_(POSIX 1003.1), 

2 

G c set from Latin-1, 

3 

all graphic characters from Latin-1, and 

255 

defined via escape sequences — the full 


scale mechanisms of ISO 2022, which are 


only rarely implemented. 


The appropriate iso committee (sci5) has 
been reconstituted with Japan supplying secre¬ 
tariat duties. A meeting is expected in July or 
September and it is hoped that there will be close 
cooperation between X3B11.1 and SC15. There is 
some concern that ansi might awaken the long- 
dormant file structure committee and that this 
might delay acceptance of X3Bll.Ts work. Also, 
because of a request by a working group involved 
in the Philips CD-WO device (a combination me¬ 
dium that is a 5.25in worm with a cd-rom por¬ 
tion), ecma might also reconstitute its file struc¬ 
ture committee (TC15). 

Finale 

What can, or should, you do? As always, I 
welcome any feedback, specific or general, on the 
work our committee does. (I must express my 
appreciation to usenix for publishing these re¬ 
ports; nearly all the mail I have received about 
X3Bll.Ts work starts off like, “I read your report 
in the so-and-so issue of ;login:. "Jin particular, I 
invite comments on any fields or attributes you 
would like standardized and — perhaps more im¬ 
portant to the UNIX community — how to access 
auxiliary information about a file in “a standard 
way. ” Plenty of ad hoc solutions already exist for 
the cases of versioned files: vms file systems on 
Ultrix systems, Macintosh files mounted as NFS 
file systems, and cd-rom file systems. The num¬ 
ber of these problems will certainly increase over 
time; we need to address the solutions now before 
we standardize on file system interfaces (such as 
1003.8) that omit such mechanisms. 

If you would like more details on X3Bll.Ts 
work, you should contact either me 
<andrew@research.att.com>, (908) 582-6262 or 
the committee chair, Ed Beshore 
<edb@hpgrla.hp.com>. I think the two most 
useful documents are the current draft of the 
working paper (about 80 pages) and a program¬ 
mer’s guide to the draft (about 12 pages written 
by me). I will send you copies of the latter doc¬ 
ument; requests for other documents or more 
general inquiries about X3Bll.l’s work would 
best be sent to Ed Beshore. 
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P1003.17 - Name Space/Directory Ser¬ 
vices (plus 1224/1224.1 Object Manage¬ 
ment) 

[Editor's note: “Object" and “objection" 
have the same root word. What follows are three 
distinct viewpoints on tcos’s object-management 
activities. The first is Mark Hazzard's overview of 
1003.17. The second is Scott Guthery’s critique of 
the object management work, currently being 
jointly done by 1003.17 and 1224. The third is 
Enzo Signore’s rebuttal of Scott’s position. After 
you read them, you might want to let the com¬ 
mittees know how you feel, either directly, or 
through Peter Collinson, the new usenix Insti¬ 
tutional Representative.] 

Mark Hazzard <markh@rsvl.Unisys.com> 
reports on the January 7-11,1991 meeting in New 
Orleans, LA: 

Introduction 

New Orleans was busy for the P1003.17 — 
Name Space/Directory Services group. It was our 
first meeting as an “official" posix “dot" working 
group, and seemed to build on the momentum 
gained in the previous meeting. A good turnout 
from the old “core” group, coupled with infusion 
of “new blood” from the X/open base-document 
development team, seemed to provide the right 
chemistry for some dynamic interchange and good 
solid progress. 

As I stated last time, our group is currently 
in the process of “POSixizing” XDS. This means 
reworking XDS to conform to posix style, content, 
and format requirements. Much of this is busy- 
work that falls largely on the shoulders of our 
(overworked) Technical Editor. A first cut at the 
new format will be included with the first mail¬ 
ings. It can be best characterized as a “very pre¬ 
liminary pre-draft,” and is intended to be a base¬ 
line from which a working draft can be built. 

Language Independent Specification 

A good deal of time was spent on Lis issues, 
both in our working sessions and in the joint 
working sessions with P1224 on common Object 
Management API issues. We were able to produce 
complete liss for several functions and their data 
types, by building on the homework done by 
group members between meeting cycles. Readers 


may want to review the complicated discussion 
from last time on how and why two specifications, 
xom (Object Management) and xds (Directory 
Services), are required to form a single API to 
directory services. Xom is also used by the API to 
X.4(to. 

Test Assertions 

Several group members had fun finding out 
how to write test assertions for the C-language 
binding of our api. We even got together with 
some P1224 folks and worked on tas for OM. We 
managed to write a few assertions and uncover 
some issues along the way. We also agreed to use 
identical conventions in .17 and P1224. During 
the process, we discovered that writing tas is not 
a well-understood art, and what everyone seems 
to be doing is looking at what everyone else is 
doing. 

Where do tas go? They could be included 
with the function specification (possibly less work) 
or lumped together into a separate chapter or 
annex (possibly more work). We’ve opted for the 
lump. The rationale for this seemingly irrational 
decision is documentation page count ($$$). We 
figured that the only people who really care about 
test assertions (besides us standards types) are 
vendors, test suite writers, certification labs, and 
a few LARGE customers, like the u.s. Govern¬ 
ment. Everyone else (users) just wants to buy 
documentation on a certified api. We wanted to 
make it really easy for the IEEE to print “with” and 
“without” versions of the standard. 

Object Management 

“Object” and “management” are two in¬ 
tensely overloaded words. Used together, the two 
can instill fear in even the most seasoned hack. 
While conjuring up a name to put on the Project 
Authorization Request (par) for our common OM 
api, the combined talent of the .17 and 1224 
groups decided that the best defense was a good 
offense and selected what may be the most of¬ 
fensive project title in the history of ieee PARdom: 
“Standard for Common ASN.l Object Manage¬ 
ment API for X.400 and Directory Services 
APIs.” If approved, it should get a number like 
P1224.1 or something like that. 

Flushed with success, the group decided to 
tackle the Scope section of the par, which prob- 
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ably constitutes its only real “meat.” After con¬ 
siderable debate the group came up with this 
statement: 

The standard will define an ASN.l Object Man¬ 
agement (OM) Application Program Interface 
(API) for use with, but otherwise independent 
of, the X.400 and Directory Service (DS) APIs, 
which are currently being standardized. An ap¬ 
plication must be able to link and use multiple 
implementations of this API. This standard will 
provide language independent specification and 
“C” language bindings. 

The words did not come without a little pain. 
The base document (xom) was produced with 
specific targets in mind, namely the asn. 1- 
encoded objects and attributes defined in the xds 
and X.400 specifications. It defines an API for 
manipulation of those objects across the API, but 
doesn’t define the objects themselves. The object 
definitions are provided in the “primary” standard 
(either xds or X.400) in a set of ASN.l constructs 
called a “package.” 

In an accompanying article, Scott Guthery, a 
group member from the user community, ex¬ 
presses concern that there is no mechanism in the 
base document for extending existing objects or 
adding new ones. This is because the object def¬ 
initions are well-defined within the context of 
their API (package) and have been hard-wired into 
the object manager. 

Vendors can provide value added to exten¬ 
sions of their products, but users cannot. Further, 
a user who purchases a product from one vendor 
that uses a (non-standard) extended package will 
have no guarantee that it will work with an object 
manager from another vendor. With the ability to 
modify or create new packages in a standardized 
way, these problems could be avoided. 

Counter arguments primarily addressed prac¬ 
tical limitations to the scope, and the technical 
infeasibility of dynamically altering packages 
(which are really protocols). See Enzo Signore’s 
accompanying article for a brief summary. The 
ability to extend an object package is not required 
for basic interoperability or portability for xds or 
X.400 apis as currently specified. A general- 
purpose user-extensible object management fa¬ 
cility may be useful, but might be technically in¬ 
feasible (or at least very difficult). It would almost 
certainly delay acceptance of apis that depended 
on it. 


Getting back to the par, the group agreed 
that the words in the scope addressed the imme¬ 
diate issue of getting an OM specification out so 
that P1003.17 and P1224 could continue. At the 
same time, the scope doesn’t shut the door on a 
more general-purpose object manager, if it’s 
deemed necessary and do-able. 

I expect this will get sorted out after our next 
meeting in Chicago, but if this continues to be an 
area of high controversy, you’ll see the topic re¬ 
surface in my future reports. 

In any case, the OM par was blessed by the 
Distributed Services Steering Committee and was 
forwarded to the TCOS SEC for further scrutiny. 

Summary 

So, that’s a peek at what’s going on in 
P1003.17. We can expect more of the same next 
time. We’ll review our progress on Lis, probably 
do more test assertions, and generally begin to 
add some flesh to the document skeleton. We plan 
to meet with P1224 for a day to continue our 
co-development effort on common api to object 
management. 

Scott Guthery <guthery@asc.slb.com> re¬ 
ports on the January 7-11, 1991 meeting in New 
Orleans, LA: 

Here Come the Objects 

X.400 (P1224) and Directory Services 
(P1003.17) have as their base documents x/open 
documents, which in turn share an x/open Object 
Management specification. At the just-concluded 
New Orleans posix meeting a Project Authori¬ 
zation Request (par) for a posix Object Man¬ 
agement standard was formulated. Here is the 
scope of the par: 

The standard will define an asn .1 Object 
Management (om) Application Program Interface 
(api) for use in conjunction with but otherwise 
independent of the X.400 and Directory Service 
(ds) apis, which are currently being standardized. 
An application must be able to link and use mul¬ 
tiple implementations of this API. This standard 
will provide language independent specification 
and “C” language bindings. 

“What does that mean?” you may ask your¬ 
self. Based on discussions during the formation of 
this par the following is my understanding. 
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The first sentence says that object classes will 
be hard-wired into the OM and that the object 
managers being considered will only instantiate 
X.400 and DS classes. Further, only vendors of 
standard-conforming software will be able to add 
classes to the om; there will be no provision on 
the standard interface for doing so. Finally, an om 
will manage only instances of classes (objects) 
that are hard-wired into itself. Not surprisingly, 
this requires the second sentence. 

The second sentence says that while the ven¬ 
dors are willing to agree on the interface, they are 
not prepared to agree on standards for objects 
themselves (even though they are all asn.1- 
based). That is, vendor A’s objects cannot be 
managed by vendor B’s object manager and vice- 
versa. Objects themselves, as manipulated by the 
object manager, are to be proprietary. This is 
primarily because many of the vendors have al¬ 
ready written object management software and 
the software that uses it, and are primarily inter¬ 
ested in formulating a standard to which they can, 
after-the-fact, claim conformance. 

The third sentence is boilerplate. 

A couple of things bother me about this 
agenda. First, I don’t like to see classes of users 

— privileged vendors who can define new classes 
vs. unwashed end-users who can only use what 
they’re given (or, more properly, what they buy) 

— institutionalized in a standard. 

Second, and really more bothersome (be¬ 
cause I suspect the first one will work itself out 
naturally), is the “requirement” for multiple con¬ 
currently executing but not interoperating 
standard-conforming subsystems. My belief is that 
we should talk this one out carefully, make darn 
sure we all know exactly what we are talking 
about, ensure we are talking about the same 
thing, and convince ourselves it’s something we 
want to enshrine in a standard. 

Isn’t this one purpose of a standard interop¬ 
eration? If interoperation is left as an impedance¬ 
matching exercise for the user, is there really a 
useful standard in play even if the user can use a 
single interface on which to do the required 
impedance-matching? Might the jaundiced eye 
view this as a truck-sized hole through which ven¬ 
dors can drive claims to standard-compliance 
while exhibiting little-to-no effective standard- 
conformance behavior? 


“Link and use multiple implementations” 
isn’t good enough. Indeed, it’s a bad idea. To me, 
it’s analogous to a hardware standard (like RS232) 
specifying little more than implementations “use 
blue wires.” I have to string a different set of blue 
wire for each vendor whose devices I purchase. 
And, what’s worse, it’s up to me to somehow get 
the information off one vendor’s wires and onto 
another vendor’s wires if I want the two vendors’ 
devices to cooperate. The standard says some¬ 
thing like “You get the information out at the 
end, which shall have 1/2 inch of bare wire.” 
Frankly, being able to buy blue wire in bulk is 
little consolation for the trouble that I have to go 
to to make the whole mess work. 

Of course, what I’m being invited to do is buy 
devices from only one vendor, which is, I suspect, 
exactly what the vendors had in mind when they 
put that “requirement” in the par. As an histor¬ 
ical note, the second sentence originally started 
off “Users require that ...” until one of the few 
users around the table pointed out that single- 
source and vendor lock-in was not high on his list 
of requirements at all and expressed surprise that 
the standards process was or could be used to 
encourage it. 

As they say in Norway, there’s owls in the 
bushes. 


Enzo Signore <enzo@retix.retix.com> re¬ 
ports on the January 7-11, 1991 meeting in New 
Orleans, LA: 

Scott Guthery doesn’t like the proposed 
1003.17/1224 approach to Object Management. I 
do. Here’s a summary of why I think Scott’s ob¬ 
jections miss the mark. 

Since a package is another way of represent¬ 
ing a protocol (a set of asn.1 productions) the 
addition of another package to the API or the 
addition of new classes to the provided API implies 
defining extensions to the protocol. Aside from 
the feasibility of doing so, it would require the 
underlying service to be able to interpret the ad¬ 
ditional ASN.l properly and to be able to encode 
and decode it. Unfortunately, it is not possible to 
do so in an implementation-independent way, 
since the OM representation of an object, even 
though it follows the asn.1 skeleton, does not 
allow the service to generate a unique asn.1 pro¬ 
duction. Said in different words, even if the client 
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application defines a new object class with some 
attributes (let’s say of primitive types — booleans, 
integers, etc.) the sole object table does not allow 
the service to generate asn. 1, since all the 
context-specific tags and the notion of seq vs. set 
are missing. 

Therefore, designing such a new interface 

will: 

1. prove wrong when the protocol cannot be 
extended; 

2. be excessively complex to define because 
of OM design; 

3. require overly sophisticated machinery in 
the service to be able to deal with generic and 
extensible object definitions. 

1003.9: FORTRAN Bindings 

Joseph J. King, Ph.D.<JKing@GCG.Com> 
reports on the January 7-11,1991 meeting in New 
Orleans, LA: 

Posix is a set of portability standards that will 
span a diverse set of architectures such as VMS, 
UNIX, and os/2. The fortran binding to posix 
system services is nearing approval. In this report 
I’ll discuss the current state, including the rela¬ 
tionship of language-independent posix standards 
to the fortran language binding, and the pos¬ 
sibility that the posix/fortran binding will be 
rejected by the International Standards Organi¬ 
zation (iso). 

Portable Operating System Interface: POSIX 

A posix standard is one of a group of stan¬ 
dards being developed by the Institute of Electric 
and Electronic Engineers (ieee), in cooperation 
with the International Standards Organization 
(iso). The primary mission of these standards is 
to define a portable user and application envi¬ 
ronment. The posix development effort is cur¬ 
rently subdivided into 19 separate numbered ef¬ 
forts — 1003.0 (posix Guide) through 1003.18 
(PEP). Taken together, these groups are forming 
operating system standards in areas that range 
from networking to real-time. Half a dozen ad¬ 
ditional groups, also supervised by the IEEE’s 
Technical Committee on Operating Systems, are 
creating related standards in areas like windowing 
toolkits. While posix started with UNIX as a 


model, posix standards are not limited to UNIX. 
For example, DIGITAL has announced a pro¬ 
gram that will incorporate some of the posix stan¬ 
dards into VMS. Once adopted and implemented, 
posix standards will define a broad range of com¬ 
patibility both within the UNIX family of operating 
systems and between other operating systems. 

POSIX and FORTRAN 

What follows is the January 1991 report on 
the progress of one of the posix working groups, 
posix. 9. Posix. 9 is responsible for defining for¬ 
tran interfaces to the posix functionality defined 
by the other working groups. As a member of this 
committee I need to keep track of the progress of 
other committees to anticipate the next set of 
interfaces we will have to develop. At the moment 
there is only one published posix standard, which 
is referred to as posix. I. 1 Posix. 1 defines the 
functionality and C interface to POSIX operating 
system services. Posix. 9 is currently in public re¬ 
view with a standard that defines fortran inter¬ 
faces to the posix. 1 system services. In addition 
to providing interfaces to system services such as 
process creation and interrupt handling, the draft 
also defines interfaces that will improve fortran 
application portability and interoperability. For 
example, the draft contains procedures for read¬ 
ing the command line arguments, performing 
stream i/o, inheriting open files, getting the time 
of day, access to system constants, access to sys¬ 
tem structures, and performing bit operations. 

“Thick” versus “thin” 

The fortran binding to posix is referred to 
as a “thin” binding. That means that it defines the 
fortran interfaces to access the posix system 
services, but does not define the functionality of 
those services. Instead, the fortran binding ref¬ 
erences the posix. 1 standard for the functional 
definitions. The Ada binding to posix is also near¬ 
ing completion. It is a “thick” binding, in that it 
defines both the Ada interfaces and functionality. 

There are advantages and disadvantages to 
each approach. Thick bindings are easier to read, 
since all the information required is contained in 
one document. Also by using the thick approach 

1. First published as IEEE 1003.1-1988, this standard 
has now been revised and updated, and achieved in¬ 
ternational status as ISO/IEC 9945-1 : 1990(E). 
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it is easier to map the functionality into native- 
language constructs. The Ada-bindings group has 
done just this and has been praised for producing 
a binding that is very Ada-like (as opposed to 
C-like). 

Thin bindings constitute a more conservative 
approach. Since functionality is not defined in the 
thin binding, there is no opportunity for errors or 
inconsistencies to be introduced. Also, thin bind¬ 
ings are easier to adapt to changes in the base 
document. For example, the fortran binding 
currently references the 1988 version of posix.1. 
Recently, however, POSIX.1 has been updated 
(1990) with several changes to functionality. After 
careful analysis at the January meeting, we de¬ 
termined that the fortran binding requires only 
one substantive change to reference the 1990 stan¬ 
dard as the base document. 


ISO Requires Language Independence 

The International Standards Organization 
(iso) at one time required all posix functionality 
to be specified by language-independent stan¬ 
dards. These are standards that specify function¬ 
ality without specifying interfaces or syntax. Thin 
binding standards are then produced for each lan¬ 
guage to provide access to the functionality. In the 
last year iso has relaxed this restriction to allow 
thick C bindings that define new functionality, but 
has excluded all other language bindings that do 
not reference a language-independent standard. 
Even though the FORTRAN binding is a thin bind¬ 
ing, it is based on the thick C binding and not a 
language-independent specification as iso re¬ 
quires. This is because there is no language- 
independent specification and such a specification 
could be a year or more away. 

As a consequence, our working group will 
forward our draft for IEEE and ansi processing 
when our work is complete. We will also ask iso 
if they wish to adopt the ieee standard at that 
time. This will give iso another chance to say yes 
or no. We hope that they will adopt our binding 
at that time. If not, it may be several years before 
a language-independent standard is developed 
and we can produce a binding to it. We feel that 
our binding has usefulness in the fortran com¬ 
munity today, so that an ansi standard, even in 
the absence of an iso standard, would be useful. 


Other issues 

Other issues discussed at the January meeting 
included Fortran 90, the ballot process, and test¬ 
ing. There was some discussion of whether the 
posix. 9 draft standard was Fortran-90- 
compatible. Since the fortran binding to posix 
only requires fortran 77 features it was agreed 
that our binding should be compatible with For¬ 
tran 90 compilers. We will look into this more 
carefully; however, after reviewing the areas in 
which Fortran 90 defines aspects for fortran 77 
that were previously undefined, I am confident 
that there are no conflicts that would prevent our 
binding from executing properly in a Fortran 90 
environment. 

I presented a short summary of Fortran 90 
features to the working group. There was a dis¬ 
cussion of which Fortran 90 features might be 
used to increase the usability and portability of 
the Fortran binding. There was interest in using 
derived types and user-defined operators to create 
an unsigned data type for Fortran — complete 
with the necessary mathematical operations. 
There was also an opinion that we should limit the 
Fortran 90 features we use to those already in 
existence in common practice (e.g., structures and 
Include). This would have the advantage that our 
Fortran 90 binding would not require a full For¬ 
tran 90 implementation and the disadvantage of 
not making the most of Fortran 90 features. 

When this is printed we will be processing 
public ballot comments. The ieee procedures for 
processing these comments was explained to us at 
this meeting. In order for our balloting to be 
successful, the following criteria must be met: 

1. We must receive at least 75% of the ballots 
sent out, and 

2. 75% of the yes-plus-no total must be yes. 

Ballots received will be of one of three types, 
yes, no, and abstain. If there are any “no” votes, 
we are required to send out the objections to all 
those in the ballot group. They will then have the 
opportunity to change their vote. We will make 
changes to the draft and repeat this process until 
the necessary 75% is met and there are no new 
objections. 

We discussed writing test assertions for our 
current draft. These assertions are used by an 
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implementor to prove conformance to the stan¬ 
dard. It was agreed that since the fortran bind¬ 
ings is a thin standard, our test assertions would 
be a thin document. 

Work to be done 

There is still much more to be done. At our 
next meeting we will be processing the public 
ballot. We hope to have a diverse range of opin¬ 
ions, and that an active balloting group will im¬ 
prove the quality of the standard. In this way, 
problems can be detected and fixed before they 
become part of the standard. If all goes well, that 
could be as soon as December 1991. 

Our next meeting will be in Santa Clara, CA 
in July, and you are welcome to attend. Please 
contact either John, Loren, or me for details. 

John McGrory (Chair) 

Hewlett-Packard 
19447 Pruneridge Ave 
Cupertino, CA 95014 
mcgrory % hpda@hplabs. hp. com 
(408) 447-0265 

E. Loren Buhle, Jr., Ph.D. 

University of Pennsylvania School of Medicine 
Rm 440A 

3401 Walnut Street 
Philadelphia, PA 19104 
buhle@xrt. upenn. edu 
(215) 622-3084 

Joseph J. King, Ph.D. 

Genetics Computer Group 
575 Science Drive, Suite B 
Madison, WI 52711 
JKing@GCG. Com 
(608) 231-5200 

1003.5: Ada Bindings 

Jayne Baker <cgb@d74sun.mitre.org> re¬ 
ports on the January 7-11, 1991 meeting in New 
Orleans, LA: 

Introduction 

The Ada Language Binding to the POSIX 
1003.1 Base Specification (P1003.5) is moving 
through the ieee ballot process. 

Now that ballot resolution has begun, the 
P1003.5 working group no longer exists; we are 


now the P1003.5 Ballot Resolution Group. We 
spent this meeting doing just that — ballot res¬ 
olution — addressing issues from our first ballot, 
chapter by chapter. This is no small task, so we 
also held an interim meeting in February. 

This report outlines some issues from the first 
round of balloting, and touches on both potential 
future Ada work and our attempts to spread the 
P1003.5 word. 


Ballot Resolution Issues 


The following is a list of those who are re¬ 
sponsible for specific sections of the P1003.5 bind¬ 
ing: 


Mitch Gart/ 

Section 

Alsys 

Steve Schwarm/ 

Section 

DEC 


Ted Baker/ 

Section 

Florida State 
Steve Deller/ 

Section 

Verdix 

Jim Lonjers/ 

Section 

Unisys 

Mitch Gart/ 

Section 

Alsys 

Steve Schwarm/ 

Section 

DEC 


Jim Moore/lBM 

Section 

Dave Emery/ 

Chaptei 

MITRE 



1 General 

2 Terminology and 
General Require¬ 
ments 

3 Process Primitives 

4 Process Environ¬ 
ment 

5 Files and Directories 

6 Input and Output 
Primitives 

7 Device- and Class- 
Specific Functions 

8 Language-Specific 
Services for Ada 

■ 9 System Databases 


Below are some things I found particularly 
interesting in the discussions they led. 


Naming Convention Issues 

One global issue, more editorial than tech¬ 
nical, but one that drew many ballot comments 
and objections, was our lack of a procedure-and- 
function-naming convention. We left names to the 
individual chapter authors, promising ourselves 
that we would address this issue later in document 
development. We never really did, but Bevin 
Brett/DEC proposed a naming convention before 
New Orleans via electronic mail, with these guide¬ 
lines: 

Eliminate multiple names with same meaning 
by picking one (e.g., change “bad,” “invalid,” 
etc. to “bad”); 
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Eliminate lengthy prefixes (e.g., change 
“POSIX_ Process. Primitives. Process. Tem¬ 
plate” to “Template”); 

Make the parameter and subtype names the 
same. 

Unfortunately, he also restructured packages 
liberally. We worried about making such sweep¬ 
ing changes after balloting had begun, but 
adopted several of his recommendations. Bevin 
agreed to revise his proposal, incorporating the 
changes accepted by the group. Chapter authors 
will evaluate the revised proposal. Accepted nam¬ 
ing changes, supported by official ballot com¬ 
ments, will be incorporated into the document. 

I/O Units 

At least one balloter requests we use “byte” 
instead of “I/O unit,” since an i/o unit is both 
“large enough to hold any member of the basic 
execution character set” and “>= 7 bits.” An¬ 
other goes farther, arguing that if “I/O unit” is 
exactly same as C’s “char” we should eliminate 
confusion by saying so. A third balloter requests 
that posix, C, and Ada character sets be somehow 
unified. 


Signals Discussion 

Many balloters objected to signal semantics. 

In the current, balloted draft (Draft 6) signals 
are interrupt entries and include semantics for 
interrupt delivery. 

P1003.4a uses a sigwait model with a single 
procedure equivalent to the Ada delay statement. 
Our current model may only support per-process 
signals, not per-thread signals, i.e., a subset of 
P1003.4a. Should we try to develop an approach 
to signals that does not break P1003.4a and 
P1003.4a/Ada? 

We also need to review P1003.4’s new signal 
proposal carefully to decide how much to change 
the P1003.5 binding to accommodate it. We do 
not know how balloters will react to such changes. 
Some balloters do not want signals tied to Ada 
tasks, because they want to use signals without 
using tasks. We could provide this, but others 
think signals without tasks is absurd. We will 
continue to work on this. 


File Descriptor Types 

File descriptor types are controversial. Bal¬ 
loters are divided on alternatives. Should file de¬ 
scriptors be private types? limited private types? 
integers? Each has its advocates. Here are sample 
arguments for making file descriptors private: 

• Arithmetic operations are available for integer 
types. Does it make sense to perform additions 
on file descriptors? 

• Sockets and P1003.4 memory-mapped files are 
used like file descriptors but may not be imple¬ 
mented as small integers, even in C; 

• In V.4 the file descriptor limit has gone from 20 
to some high number (4K?), making arrays of 
file descriptors less practical. (Array indexing 
with file descriptors is arguably bad C program¬ 
ming style anyway.) 

Despite such arguments, we left file descrip¬ 
tors integer types because of the P1003.1 standard 
(note the definition of dup(2)). We noted in the 
rationale that we could have made file descriptors 
a private Ada type, required that they look like 
integers, and included special operations to dis¬ 
allow arithmetic functions on them, but the group 
thought that this would be too cluttered. File 
descriptors are acceptably close to integers. 

Blocking Behavior 

Tasks are a major source of complaints for 
UNIX Ada users. No one wants a whole process 
to block when one task within that process per¬ 
forms i/o or waits for a file lock. Unfortunately, 
P1003.1 doesn’t support threads; blocking blocks 
an entire process, so our document provides sup¬ 
port for per-process blocking. Should it also pro¬ 
vide per-task blocking? Making implementors 
provide both behaviors could prove to be the 
wrong decision once POSIX supports threads. 

After some discussion, two models for block¬ 
ing were proposed: 

• the knife-switch model, and 

• the file model. 

A knife-switch-model implementation elects 
either program blocking on i/o or task-level 
blocking on i/o for all files. Only one is supported. 
A file-model implementation selects either task- 
or program-level blocking for i/o on a per-file 
basis. 
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Mitch Gart suggested we relax our text in 
several places to allow alternative behaviors. He 
argued that separate predicates for blocking or 
non-blocking behavior are unnecessary because 
users will specify one or the other when files are 
opened; on the other hand, each system should 
provide an inquiry function that returns the block¬ 
ing behaviors it supports. 

We will add a statement to the normative 
conformance definition section (got all that?) say¬ 
ing that a strictly conforming application shall not 
depend on either task blocking or program block¬ 
ing. 

Future Work 

Test Assertions for Current Work 

To become an ieee standard, the P1003.5 
document must include test assertions. Jim Leath- 
rum of Clemson University and his graduate stu¬ 
dents have volunteered to develop a set. We like 
this approach because the assertion writers will 
lack the working group’s preconceptions and bi¬ 
ases. Also, we won’t have to do the work, and it 
frees the working group to press forward to other 
important POSix/Ada tasks. We are well into the 
ballot process and will probably defer the test 
assertions to a separate document. 

Ada Binding to Shells and Utilities (P1003.2) 

Dave Emery continues to develop the Ada 
binding to P1003.2. 

Ada Binding to Real-Time Extensions to POSix 
(P1003.4) 

Mars Gralia of Johns Hopkins University of¬ 
fered to put together an Ada/P1003.4 Project Au¬ 
thorization Request (par) broad enough to cover 
both the P1003.4 and .4a work. Ted Baker 
(former .5 snitch) generously provided the paper 
“Realtime Extension for Portable Operating Sys¬ 
tems Ada Binding,” some months back, which we 
will use as a starting point. We are currently 
refining a schedule to include in the PAR. 

Spreading the P1003.5 Word in Europe 

In my last report, I said that our group is 
making a real effort to educate people about the 
coming POSix Ada Language Binding Standard. 


Dave Emery of mitre submitted a team proposal 
for a tutorial at Ada Europe in Athens, Greece. 
It was accepted and scheduled as a half-day ses¬ 
sion for May 17, 1991. Unfortunately, we will 
probably cancel it because travel to Greece is 
currently discouraged. 

POSIX Profiles 

Jim Isaak <isaak@decvax.dec.com> reports 
on the January 7-11, 1991 meeting in New Or¬ 
leans, LA: 

The posix profile standards projects differ 
radically from the other posix activities. Most 
posix projects focus on specific interface specifi¬ 
cations and, for the most part, on operating sys¬ 
tem services. The profile documents will neither 
define new interfaces nor be limited to operat¬ 
ing system considerations. 

What’s a Profile? 

The starting point on profiles is the grand 
experiment of osi. By 1978, the osi world had 
created a “complete” seven-layer model of com¬ 
munications and were ready to start developing 
standards that would populate that model. By 
1988, over 140 standards had been accepted to fit 
into the seven layers. Any specific OSI implemen¬ 
tation would pick some seven of these 140 stan¬ 
dards, and specify any further options and pa¬ 
rameters required by any of the standards. 

The probability of two arbitrary, different osi 
systems interoperating was nil. The solution ad¬ 
vanced by OSI to this dilemma was to define a new 
kind of document — a profile — that specified the 
suite of standards, options, and parameters 
needed to meet a specific functional objective; 
indeed, profiles are also called “functional stan¬ 
dards” (which says something about other stan¬ 
dards). 

The idea of profiles transcends OSI. For ex¬ 
ample, de facto profiles are commonplace. If you 
go into your local computer store and ask for “a 
PC with MS/DOS, Windows 3, a C compiler, and 
Lotus 1-2-3,” that’s a profile for your functional 
needs. Even the X/Open “Common Application 
Environment,” which consists of several compo¬ 
nents described in their seven-volume X/Open 
Portability Guide, might be considered a profile, 
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although it is not clear that it would satisfy a 
specific functional objective. 

‘ The U.S. Government National Institute for 
Standards and Technology (nist) introduced an 
“Applications Portability Profile 1 ’ with their fips- 
151 in 1988 1 , which has the same problem: the 
nist “profile” is a collection of standards and 
other interface specifications with no focused 
functional objective. 

POSIX and Profiles 

P1003.10 is the first ieee posix profile 
project, and its functional objective is more ex¬ 
plicit: Supercomputing. The question this group is 
asking is, “what set of standard interfaces pro¬ 
vides the complete environment supercomputing 
users need for applications portability, interop¬ 
erability, and consistency of user interface?” 
Some standards identified so far are fortran 
(F77), POSIX. 1, GKS, and phigs. 

The nasty word is “complete.” It does not 
take much insight to see that even combinations 
of standards won’t be complete enough for some 
sophisticated applications. Application environ¬ 
ment profile groups also must identify areas where 
additional standards are needed. This is a second 
value of profiles: supplementing the “roadmap 
though the maze” goal of osi profiles. At a min¬ 
imum, profile groups should document require¬ 
ments not addressed by the standards, to help 
vendors and users ensure missing capabilities are 
provided, even if they’re not standardized. 

For supercomputing, for example, perfor¬ 
mance requirements fall into this category. Some¬ 
times, profile groups can do more than just doc¬ 
ument, though. What happens, for example, if the 
profile work reveals the need for an interface that 
isn’t yet standardized? There are two possibilities. 
First, the profile group can tell an existing stan¬ 
dards group working in a related area they need 
the new interfaces (and offer expert aid, if nec¬ 
essary). If that doesn’t work, the profile group can 
try to spin off a new group or at least a new 
project. For example, the supercomputing profile 
work has already spun off two projects: the 
P1003.9 working group, which is providing FOR- 


1. They have recently published an expanded view of 
this for public comment. 


tran interfaces to posix. 1, and the P1003.15 
project for batch services. 2 

Other posix profile projects already under¬ 
way are transaction processing (.11), real time 
(.13), and multiprocessing (.14). 

PEP: a prototype standard 

Right now, profiles are being generated 
bottom-up, starting from real-world problems, le¬ 
veraging existing standards, and exposing gaps. 
There is no formal model for applications port¬ 
ability, and few users are willing to wait for one. 
In an ideal world, with some well-understood for¬ 
mal model of a complete computing environment, 
standards might be generated top-down, much 
like the osi approach. How do we grope our way 
to such a model? 

At the international level, Technical Study 
Group 1 (tsgi), is just finishing recommendations 
to iso on “interfaces for applications portability,” 
which will include some modeling concepts for a 
top-down approach. The most solid recommen¬ 
dations coming out of this work will advocate the 
extension of iso profiling work beyond osi to 
address applications portability and to help iden¬ 
tify requirements for standards work. 

Industrial groups, like the Petrotechnical 
Open Software Company (posc), are also inter¬ 
ested in profiles (for “upstream” petroleum en¬ 
gineering applications). The European Workshop 
on Open Systems (ewos) is also expanding their 
charter from osi profiles to application portabil¬ 
ity. Much early groundwork for OSI profiles was 
developed by folks now in ewos, and much of 
ewos’s current work is to establish a framework 
and a set of procedures for this larger problem 
space. 

The ieee’s tcos is taking a different ap¬ 
proach: sort of rapid prototyping for standards. 
The most recently approved ieee posix project is 
P1003.18, the posix Platform Environment Pro- 

2. The “batch services” work isn’t just batch processing. 
In the world of supercomputing, jobs can run beyond 
either the system’s mtbf — mean time between failures 
— or its mtbshpjtyofaw — mean time before some 
higher priority job throws you out for a week. To 
handle this with some grace, applications “checkpoint” 
their state and can restart from that state. Extended 
services for checkpoint and restart are part of the .15 
task. 
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file (pep). A simplistic statement of its goal is, “to 
define the standards which together describe what 
folks have traditionally called UNIX”: — POSIX.1 
plus POSIX.2 plus the C standard. 3 

Its real goal, though, is to address three 
closely related needs. 

1. PEP will provide a common foundation 
(platform!) for the more focused application en¬ 
vironment profile projects (.10, .11, ...). 

2. It will help all users of the posix standards 
to understand the line between the traditional 
“Unix” space and any new work of the posix 
groups. This does not mean that pep will not 
include some new work over time, but it will 
identify a useful stable ground (platform!) in the 
rapid evolution of posix standards. 

3. Profiles are new to ieee, ansi, and ISO, and 
a simple example will help folks to get a handle 
on what profiles are all about. Pep provides a 
simple case, building on posix. 1 (system inter¬ 
faces), posix.2 (and .2a) (commands), the C lan¬ 
guage, and potentially Ada and posix.5, and/or 
fortran and posix.9. 

In effect, PEP will blaze the trail for other 
more complex profile tasks, like supercomputing 
or transaction processing, and will be a stepping 
stone (platform!) for those efforts, providing 
them a clearer path into iso. 

Profiles as Configuration Management Tools 

The second point above may need explain¬ 
ing. Profiles take a snapshot of the standards at 
a point in time. Supercomputing is specifically 
selecting fortran 77 because it matches today’s 
needs. Fortran 4 will evolve. A future version of 
posix. 10 may include a future version of Fortran. 
The array of standards is moving forward asyn¬ 
chronously, and often chaotically; profiles group 
together standards to provide a form of “release 
control” or “configuration management.” An ap¬ 
plication and a system can refer to a specific ver¬ 
sion of a specific profile. 


3. Of course, many readers will argue that this is hope¬ 
lessly incomplete (“How can you have a UNIX system 
without emacsl ”), but bear with me. 

4. The next generation Fortran is properly presented in 
mixed case, by committee decree, whereas historically 
fortran has been an acronym and all upper case. 


Benefits Profiles Will Bring 

Profiles provide an easy way for users, ap¬ 
plication developers, and vendors to describe en¬ 
vironments. Application developers and isv’s will 
finally have a clear target-space for development. 
Profiles will tell customers what facilities the tar¬ 
get systems for their software supply. Eventually, 
we will see conformance testing of integrated pro¬ 
files, providing a higher level of confidence in the 
environment. 

1003.6: Security Extensions 

Ana Marfa de Alvar6 <anamaria@sgi.com> 
reports on the January 7-11,1991 meeting in New 
Orleans, LA: 

Overview 

The P1003.6 group met for the entire week. 
Our main task was preparing draft 8 for mock 
ballot. We also planned for P1003.6 test assertions 
and discussed file locking, manipulating or dupli¬ 
cating the information in opaque data objects, 
and allowing ps to show privileges and mac labels 
of processes. 

We also heard two proposals at the meeting, 
one on Privileges and one on Discretionary Ac¬ 
cess Control, which I discuss in the relevant sub¬ 
group sections below. 

Mock Ballot 

P1003.6 plans to go to mock ballot after our 
April meeting. We will review comments at the 
July meeting, and try to ballot the document soon 
afterwards. The October meeting will be used for 
ballot resolution and clean-up. 

To prepare for mock ballot, the working 
group submitted written comments on the current 
draft, and subgroups spent the week addressing 
them. Commenters included Chris Hughes (icl), 
Roland Clouse (Unisys), Dan Ujihara (SUN), 
and me (sgi). 

Test Assertion Plans 

The group decided to create a separate test- 
assertions document that parallels the current 
document. Each subgroup will be responsible for 
its own test assertions, and will ensure that the 
assertions document and the main document re- 
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main consistent (i.e., any updates to the P1003. 
6 document will trigger changes to the assertions 
document). Dave Rogers of Data Logic and I are 
co-chairing this effort. If you are interested in 
helping to write test assertions, please let us 
know. 

Opaque Security Data Object Duplication 

Duplicating the information in opaque secu¬ 
rity data objects — acls, labels, and privileges — 
presents three distinct kinds of problems: 

1. duplicating the information within a pro¬ 
cess, 

2. passing the information between processes 
in a single system, and 

3. exporting the information out of a system. 

Copying the information within a process is 
simple. What’s hard is copying it out of the pro¬ 
cess’s context — for example, for backups. We 
decided that such exporting will require passing 
out both object addresses and sizes, as well as 
data characteristics, such as binary , text , or func¬ 
tion. 

Privileges 

John Griffith (hp/apollo) presented a new 
privileges proposal that simplified determining 
whether a process has, lacks, or inherits a priv¬ 
ilege. 

In draft 8, a process could only inherit a 
privilege if the “allowed” file-privilege attribute 
was set: inheritance, through the inheritable 
group, depended on restrictions provided by the 
“allowed” file privilege attribute. 

The subgroup agreed that this needed sim¬ 
plifying. The newly agreed-on substitute is that a 
privilege can be inheritable if it exists in the in¬ 
heritable group or if the file’s “forced” privilege 
attribute is on. In other words, after an exec 
occurs, a privilege that is on in the inheritable 
privilege group can turn itself on in the permitted 
privilege group. 

The subgroup spent much of the remaining 
time editing its part of the document. Two issues 
I hope will be resolved next meeting are: 

1. accommodating privileged shell scripts in 
the current proposal, and 


2. determining how to store privilege infor¬ 
mation for later use. 

Discretionary Access Control 

The new dac proposal consisted of two doc¬ 
uments representing a collaborative effort by Paul 
Karger (osf), Rand Hoven (hp/apollo), and Jon 
Spencer (Data General). It tried to simplify the 
way default acls and mask_objs work, and it 
removed any requirement for mask_ OBJ entries 
when no additional ACL entries existed. In the 
end, we decided to retain the old scheme but will 
try to shore up areas that the new proposal 
pointed out were particularly weak. The propos¬ 
al’s sponsors agreed to this, providing the new 
draft offers a satisfactory alternative simplifica¬ 
tion. 

The subgroup also attacked the opaque ob¬ 
ject issue described earlier, defining an interface 
to interconvert dac opaque objects and text 
strings, and a relocatable ACL format that can be 
stored in an audit record. 

The dac subgroup will pass their draft to the 
full group after the next meeting. 

Mandatory Access Control 

The mac subgroup discussed the written 
comments to their section and feel they will be 
ready for ballot after the next meeting. 

Two major issues arose: 

1. whether our document should address spe¬ 
cial (block and character device) files, and 

2. whether we needed a dup()-\ikQ function 
to copy internal formats. 

The subgroup decided the current version of 
P1003.6 shouldn’t address terminals or other spe¬ 
cial files, but the second issue will be passed on 
to the entire group. 

Audit 

The Audit subgroup discussed all the written 
comments and will only need one more meeting 
to be ready for ballot. Their work, including man¬ 
datory record types, will be based on x/open’s. 
They will not address Portable Data Record For¬ 
mat, and optional record types will be 
implementation-defined. 
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Clearly, audit functions will need both point¬ 
ers to objects and their sizes to operate on mac, 
dac, and Privilege opaque data. Because of this, 
I predict all three subgroups will have to provide 
interfaces to provide the information. 

Liaison ,6/.7/.8 

The liaison group met again to discuss areas 
of compatibility and overlap between our respec¬ 
tive documents. (The October P1003.6 snitch re¬ 


port sketches our ongoing agenda.) We identified 
areas that P1003.6 (Security), P1003.7 (System 
Administration), and P1003.8 (tfa) already han¬ 
dle, areas we might handle, and areas that are 
falling through the cracks. After we finish iden¬ 
tifying areas of concern, we may write pars for 
anything we cannot farm out to existing groups. 
In April, we will discuss how to report our find¬ 
ings back to the three groups. 


Request for Proposals to Chair the 
Summer 1993 USENIX Technical Conference 


The Association is seeking proposals from 
people interested in serving as the Technical 
Program Chair for the 1993 Summer Conference, 
to be held June 21-25 in Cincinnati, Ohio. 

We are seeking an energetic person with the 
following qualifications: 

Excellent administrative and public speaking 
skills 

Knowledge of the timely and appropriate topics 
in the field 

Ability to solicit good panel members and 
appropriate speakers 

Attendance at previous usenix conferences 
Ability to work together with usenix staff, 
volunteers and the invited talks committee 

Proposals should be brief (one page), includ¬ 
ing the following points: 

a. conference: date and location 

b. statement of purpose 

c. preference for member of the Board of 
Directors who will serve as liaison. 

d. form of submissions: abstracts, extended 
abstracts, or full papers. 


e. special format: such as three days, one 
each on x, y, and z. 

f. list of topics to be addressed, as in a call 
for papers. 

g. track preference: single or double 

h. any special features, such as plans for im¬ 
proving the quality of papers. 

i. list of potential program committee mem¬ 
bers or a description of its possible composition, 
to include biography and references. (The Board 
has the option to appoint someone to the com¬ 
mittee in addition to the forthcoming chairs.) 

Proposals are subject to approval by the us¬ 
enix Board of Directors. Details concerning the 
schedule, site, and call for papers will be arranged 
with the Association after the appointment of the 
chair has been made. 

Proposals are due: August 15, 1991. 

Please address all inquiries and proposals to 
the Association’s Executive Director, Elbe Young 
(ellie@usenix.org). 
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USENIX Board of Directors’ Meeting 


Below is a summary of the actions taken at 
the recent quarterly meeting of the usenix Board 
of Directors held in Falls Church, Virginia on 
March 23 and 24, 1991. 

Attendance: 

Rick Adams, Ed Gould, Rob Kolstad, Kirk 
McKusick, Sharon Murrel, Evi Nemeth, Michael 
O'Dell, Barry Shein, Deborah Scherrer, Ellie 
Young. 

It was suggested that usenix should become 
a conglomerate, using the model of ACM and its 
Special Interest Groups (SIGs), and that having 
a SIG of users of a particular vendor's equipment 
is okay. Adams would draft a proposal for the 
development and maintenance of SIGs. 

Gould and O’Dell offered to look into the 
feasibility of usenix providing a snitch report-like 
patent publication, to identify software patents 
and report on their status. 

The 1991 subscription to the proceedings will 
be offered at $140 for members and $170 for 
non-members. 

It was decided that it be the policy of the 
Board of Directors that the people who constitute 
the nominating committee for the Board of Di¬ 
rectors elections not include any person who in¬ 
tends him or herself to be a nominee. 

The following decisions pertaining to the con¬ 
ferences were made: 


1992 Elections 


Peter H. Salus, Executive Director of the Sun 
User Group, Managing Editor of computing 
systems, and former Executive Director of 
usenix will chair the Nominating Committee for 
the 1992 usenix Board elections. 


That the invited talks be assured of enough 
space to conduct at least one full track in parallel 
with the refereed papers, and the invited talks 
committee determines the format and content of 
the invited series and shares the same autonomy 
for them that the conference program chair ex¬ 
ercises for the refereed papers. 

That the Board consider how to seed the 
Work in Prorgress Sessions, and encourage more 
involvement. 

That the Face Saver service not be offered in 
Nashville, and that Lou Katz be thanked for his 
efforts over the past years. 

That the 1995 Summer Conference will be 
held in San Francisco on June 19-22. 

That beginning in 1996, the Winter Confer¬ 
ences alternate between San Diego and San Fran¬ 
cisco, and the staff should investigate Toronto, 
Boston, Baltimore, and Minneapolis, as possible 
cities for rotation of future summer conferences. 

That offering basic tutorials would broaden 
the scope of the conferences, and the tutorial 
coordinator and review committee should look 
into this. 

The next regular meeting of the Board will be 
held on June 9 and 10, at the Nashville Confer¬ 
ence. The Annual Meeting of the Association will 
be held on June 12, 1991 in Nashville, as well. 


Peter would like anyone interested in running 
for office, those who are interested in nominating 
someone, and members who would just like to 
make suggestions to get in touch with him via 
email (peter@usenix.org) or face-to-face in Opry- 
land. 
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1990 Annual Fiscal Report - USENIX ASSOCIATION 

Balance Sheet 

For the Fiscal Year ended November 30, 1990 


ASSETS 
Current Assets 


Cash & Cash Equivalents 

Prepaid Expenses 

Inventory-Proceedings 

Note Receivable (Note 3) 

Current Assets 

976,007 

72,767 

48,542 

115,000 

1,212,316 

Fixed Assets 

Office Furniture & Equipment 

Less Accumulated Depreciation 

Fixed Assets 

225,941 

(144,845) 

81,096 

Total Assets 

1,293,412 

LIABILITIES & FUND BALANCE 

Liabilities 

Accrued Expenses 

Deferred Revenue 

65,881 

20,335 

Liabilities 

86,216 

Fund Balance 

1,207,196 

Total Liabilities & Fund Balance 

1,293,412 


Notes to Financial Statements 

For the Fiscal Year ended November 30, 1990 

1. Organization 

The Association was incorporated in 1980 and was granted 
status as a non-profit organization exempt from income 
taxes under Section 501(c)(3) of the Internal Revenue Code 
in 1987. 

2. Summary of Significant Accounting Policies 

The Association maintains its books on the accrual basis of 
accounting. Deferred revenues are amounts received during 
the current year which relate to conferences and workshops to 
be held in the subsequent year. Prepaid expenses are expenses 
which have been paid in the current year, but relate to conferences 
and workshops to be held in future years. It was not feasible to 
include in the opening balances for this current fiscal year, 
amounts which, under generally accepted accounting principles, 
should have been accrued as prepaid expenses, accrued expenses 
and deferred revenues as of the beginning of the year. 

Furniture and equipment are recorded at cost and depreciated 
on a straight-line basis over their respective estimated 
useful lives, which range from five to seven years. 

3. Note Receivable 

The note receivable is from UUNET Technologies, Inc. The note, 
which is dated October 1, 1990, consolidated and replaced all 
other amounts owing to the Association from UUNET as of 
that date. This note has an unpaid balance of $115,000 as 
of November 30, 1990. The note calls for monthly payments 
of $10,000, plus interest thereon at the prime rate. The final 
payment, in the amount of $5,000 plus interest, is due on 
November 1, 1991. 


4. Retirement Plan 

In 1986, the Association adopted a defined contribution pension 
plan lor its employees. Contributions are made on behalf of 
employees at the rate of 10% of an eligible employee’s 
compensation. The amount contributed to the plan for the 
fiscal year ended November 30, 1990 was $26,907. 

5. Lease Obligation 

The Association leases approximately 2,910 square feet of 
office space at its Berkeley, California location under 
terms of a lease dated January 13,1987. The present annual rent 
is approximately $55,000 and the lease expires February 2], 1992. 
The .Association also leases 1,152 square feet of office space at its 
El Toro, California location under terms of a lease dated 
March 14, 1989. The present annual rent is approximately 
$17,800 and the lease expires March 31, 1992. 

6. Inventory—Proceedings 

The inventory on hand, as shown on the Balance Sheet, consists 
of the stock of proceedings of prior conferences and workshops. 
These copies are available to be sold to members and other 
interested persons. Inventory is valued at cost, based on the 
specific identification method. 

7. Fund Balance 

The Association maintains a large fund balance partly as a 
contingency fund, so that if a conference does not meet income 
projections the Association will still be able to provide basic 
services to the membership. 
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Statement of Revenue and Expenses - USENIX ASSOCIATION 

For the Fiscal Year ended November 30, 1990 


REVENUE 


Membership Dues 

236,090 

Product Sales 

136,382 

C++ Conference 

157,958 

Security Workshop 

50,770 

Mach Workshop 

37,691 

LISA IV Conference 

94,191 

Winter Conference 

509,847 

Summer Conference 

628,364 

Exhibit Income 

159,485 

Professional Development Seminars Income 

34,435 

Interest Income 

92,344 

Miscellaneous 

3,239 

Total Revenue 

2,140,796 

EXPENSES 

Executive Office G & A 

342,490 

Executive Office Personnel 

169,234 

Exhibit Office G & A 

56,740 

Exhibit Office Personnel 

116,614 

Exhibit Site Expenses 

40,829 

Professional Development Seminars 

31,161 

Conference Office G & A 

57,999 

Conference Office Personnel 

59,539 

Conference Coordinator Fees 

204,505 

C++ Conference 

79,999 

Security Workshop 

17,989 

Mach Workshop 

14,514 

LISA IV Conference 

29,074 

Winter Conference Expenses 

278,320 

Summer Conference Expenses 

421,124 

Membership Services 

136,000 

Products Expenses 

78,842 

Projects Expenses 

105,539 

Miscellaneous 

0 

Depreciation 

40,496 

Total Expenses 

2,281,008 

Excess Revenue over Expenses 

(140,212) 

Fund Balance as of November 30,1989 

1,347,408 

Fund Balance as of November 30,1990 

1,207,196 
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1990 USENIX MEMBER SURVEY RESULTS 

In December 1990, USENIX members were sent a questionnaire seeking their opinions concerning several projects 
the Association has been considering, and to gain additional information about you, the membership. USENIX is 
entering a period of exciting growth and tremendous challenge. This feedback is essential in helping us to plan in 
the coming years. 

The survey was mailed to 4402 members. We received 2201 responses - a whopping 50% rate of return! Below 
are the results. We would appreciate any suggestions you might have that can be incorporated into future surveys. 
Please contact the Executive Director (ellie@usenix.org). 

Total number of surveys tabulated: 2201 


Membership Class: 



Individual 

1413 

64% 

Corporate 

72 

3% 

Educational 

109 

5% 

Student 

76 

3% 

Not Identified 

534 

24% 


ANNUAL CONFERENCES 

1. Please indicate your interest in holding meetings at the same time as UniForum 
Winter Conferences. 


Meet with UniForum 

784 

37% 

Do not switch to meet with UniForum 

485 

23% 

Do not care 

871 

41% 


2. On average how many USENIX conferences do you attend each year? 


None 

571 

26% 

One 

1402 

65% 

Two 

196 

9% 

Do you usually attend the Winter Uniforum conference? 

Yes 

685 

34% 

No 

1350 

66% 

What percentage of your expenses do you pay personally? 

0 

1180 

62% 

Less than half 

386 

20% 

Half 

91 

5% 

More than half 

22 

1% 

100 

227 

12% 


♦Except for Questions 5,7,10, and 15, all percentages indicate percent of total responses to one particular 
question, not the percent of the total number of surveys received. 
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5. Do the invited talks and panels: 

% of Responses 

% of Total 


To This Question 

Surveys 

Increase your interest in attending our conferences 

1643 56% 

75% 

Help you justify your attendance to your mgmt. 

955 33% 

43% 

Make no difference 

312 11% 

14% 


6. Please indicate how many invited talks should be offered at each conference? 
(Please check only one.) 


Expand to full day of sessions. 

299 

14% 

As now, 5-6 per conference. 

1370 

65% 

None. 

12 

1% 

Do not care. 

421 

20% 


PROJECTS 

7. Please indicate your choice(s) regarding the roles that you feel USENIX should 
play in standards: 




% of Responses 

% of Total 


To This Question 

Surveys 

Pro-active: POSIX balloting 

1045 

15% 

47% 

Pro-active: POSIX Institutional Representative 

1079 

16% 

49% 

Informative: report on int'l standards group WG15 

1088 

16% 

49% 

Informative: snitch reports 

1238 

18% 

56% 

Informative: moderated newsgroup 

966 

14% 

44% 

Informative: BOFs at conferences 

1050 

16% 

48% 

USENIX should not be involved in standards 

57 

1% 

3% 

Do not care 

221 

3% 

10% 


8. Should USENIX distribute Berkeley 4.4 manuals? 


Yes 

1444 

66% 

No 

187 

9% 

Do not care. 

541 

25% 


9. Should USENIX support the editing of license-free Berkeley 4.4 manuals 
which would be available for use in on-line systems? 


Yes 

1370 

64% 

No 

217 

10% 

Do not care. 

554 

26% 
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10. Please check all the roles USENIX should play in software patent issues: 


Pro-active: contest software patent applications 

1424 

% of Responses 

To This Question 

50% 

% of Total 
Surveys 
65% 

Informative: Produce patent snitch reports 

1175 

41% 

53% 

No software patent activities 

114 

4% 

5% 

Do not care 

141 

5% 

6% 

11. Please indicate your interest in FaceSaver. 

Do FaceSaver at each meeting 

749 

35% 


Do FaceSaver only at the summer meeting 

161 

7% 


Do FaceSaver only at the winter meeting 

91 

4% 


Do not do FaceSaver at all 

471 

22% 


Do not care 

681 

32% 



USENIX PUBLICATIONS 

12. How would you rate the usefulness of each of the following parts of ;login:? 



Poor 

Adequate 

Excellent 

Don't know 

Mean 

Median 

Standard 


0 

1 

2 

3 

4 

5 



Deviation 

Book reviews 

18 

61 

■Si 

813 

434 

342 





1% 

3% 

B 

39% 

21% 

16% 

2.91 

3 

0.84 

Information on work- 

15 

33 

401 

827 

520 

285 




shops & conferences 

1% 

2% 

19% 

40% 

25% 

14% 

3.00 

3 

0.81 

Information on other 

33 

168 

622 

621 

199 

437 




user groups 

2% 

8% 

30% 

30% 

10% 

21% 

2.47 

2 

0.82 

Standards snitch reports 

22 

69 

337 

753 

518 

371 





1% 

3% 

16% 

36% 

25% 

18% 

2.98 

3 

0.88 

Total Responses 

88 

331 

1773 


1671 

Kj|gM| 





1% 

4% 

21% 

36% 

20% 


2.85 

3 

0.89 


13. How would you rate the following aspects of Computing Systems? 



Poor 

Adequate 

Excellent 


Mean 

Median 

Standard 


0 

1 

2 

3 

4 

5 



Deviation 

Appropriateness of 

7 

52 

283 



468 




articles 

0% 

3% 

14% 



23% 

3.06 

3 

0.81 

Quality of articles 

6 

25 

166 

734 

671 

468 






1% 

8% 

35% 

32% 

23% 

3.27 

3 

0.74 

Timeliness of 

23 

87 

402 


329 

522 




publication 

1% 

4% 

19% 

34% 

16% 

25% 

2.79 

3 

0.89 

Appearance of the 

11 

36 

269 

636 

644 

461 




journal 

1% 

2% 

13% 

31% 

31% 

22% 

3.17 

3 

0.83 

Total Responses 

47 

200 

1120 

2821 

2155 

1919 





1% 

2% 

14% 

34% 

26% 

23% 

3.08 

3 

0.84 
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DEMOGRAPHICS 


14. Please give the two letter postal abbreviation for your state or province: 





% of U.S. 

% of Total 



U.S. 


Membership 

Responses 

Top Ten States 

New England 


201 11% 

10% 

CA 

588 

(CTMA,MEJVHJU,VT) 




MA 

152 

Mid-Atlantic 


424 23% 

21% 

NY 

121 

(DC £>EMD JVJJVYfA.VA) 




TX 

103 

Midwest 


127 7% 

6% 

NJ 

100 

(ILJN.KY MI.OH.WV) 




MD 

84 

Southeast 


87 5% 

4% 

CO 

65 

(ALfL.GA JAMS JVC,SC.TN) 



WA 

52 

South Central 


134 7% 

7% 

VA 

50 

(AR,KSMO,OK,TX) 




IL 

48 

North Central 


62 3% 

3% 

OR 

48 

(IAMNJVDJVE.SD.WI) 




PA 

48 

Rockies 


129 7% 

6% 



(AZ, COJDMTJVM.UT.WY) 






Pacific West 


699 38% 

35% 



(AK.CAJIIJW.OR.WA) 








% of Canada 

% of Total 



Canada 


Membership 

Responses 



Alberta 

8 

10% 

0% 



British Columbia 

12 

15% 

1% 



Newfoundland 

1 

1% 

0% 



Nova Scotia 

1 

1% 

0% 



Ontario 

48 

60% 

2% 



Quebec 

9 

11% 

0% 



Saskatchewan 

1 

1% 

0% 



Other % of Total Responses: 

3% 



Australia 

14 

Iceland 

1 

New Zealand 


Brazil 

1 

Italy 

1 

Norway 


Denmark 

4 

Japan 

6 

Sweden 


Finland 

2 

Korea 

2 

Switzerland 


France 

1 

Malaysia 

2 

United Kingdom 

Hong Kong 

1 

Netherlands 

1 

& Great Britain 

15. Please indicate the networks to which you have access: 







% Of Responses 

% of Total 




To This Question 

Responses 


Internet 1574 

40% 


72% 



Usenet 1537 

40% 


70% 



Bitnet 560 

14% 


25% 



Other 219 

6% 


10% 


Other networks mentioned: AppleLink, ARPANET, ASCNET, AT&T, BARRNet, BIX, CSNet, DECNET, EOS, 
GSFCMAEL, JUNET, Private/Intemal, Milnet, NORDUnet, NSFNET, SPAN, SURAnet, UUCP, UUNET, VNET 
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16. Please indicate your primary employer: 


Business/corporation 

1297 

60% 

Educational institution 

427 

20% 

Government agency/military 

133 

6% 

Nonprofit organization 

45 

2% 

Research Facil. 

119 

5% 

Self-employed 

105 

5% 

Student 

28 

1% 

Retired 

2 

0% 

Other 

22 

1% 

17. What is your primary job position? 

Executive or senior manager 

240 

11% 

Dean/Chair 

23 

1% 

Project leader 

332 

16% 

Researcher 

113 

5% 

Programmer or Technical staff 

1097 

52% 

Professor or instructor 

7 

0% 

Consultant or self-employed 

144 

7% 

Student 

51 

2% 

Retired 

2 

0% 

Other 

103 

5% 


18. What is your annual salary? 


Less than $10K 

35 

2% 

S10-25K 

60 

3% 

$25-50K 

780 

38% 

S50-75K 

857 

41% 

$75-100K 

260 

13% 

$100-150K 

71 

3% 

$250K or more 

6 

0% 


19. What is the highest level of education you have completed? 


High school 

32 

1% 

College without a degree 

229 

11% 

Bachelor's degree 

682 

31% 

Graduate work 

293 

14% 

Masters 

696 

32% 

Doctorate 

195 

9% 

Postdoctorate 

42 

2% 
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20. How old are you? 


Less than 25 

99 

5% 

25 to 34 

1041 

49% 

35 to 44 

753 

35% 

45 to 54 

212 

10% 

More than 54 

30 

1% 

Mean 

34.8 


Median 

35 


Std. Deviation 

7.39 


. How many years using UNIX? 



Less than 2 

68 

3% 

2to5 

603 

28% 

6 to 10 

1039 

48% 

11 to 15 

386 

18% 

16 to 20 

66 

3% 

More than 20 

5 

0% 

Mean 

7.8 


Median 

7 


Std. Deviation 

3.91 


How many years have you been a member of USENIX? 


Less than 2 

679 

32% 

2to5 

1081 

51% 

6 to 10 

329 

15% 

11 to 15 

41 

2% 

More than 15 

2 

0% 

Mean 

3.4 


Median 

3 


Std. Deviation 

2.72 
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SUBSCRIPTION ORDER FORM 


PROCEEDINGS 

Please enter my one-year subscription* to the 1991 USENIX Conference, Workshop and Symposium 
Proceedings, which include: 

Dallas Conference - January 1991 

Software Development Environments Workshop in UNIX - January 1991 
Distributed & Multiprocessor Systems II (SEDMS) - March 1991 
C++ Conference - April 1991 
Nashville Conference - June 1991 

Large Installation Systems Administration V Conference - October 1991 
Mach Symposium - November 1991 

COST: USENIX members: $140.00 Non-members: $170.00 

Outside U.S.A. and Canada? Add $30.00 for surface postage. 

PAYMENT OPTIONS 

Check enclosed payable to USENIX Association. □ Purchase order enclosed. 

Please charge my: \^\ Visa LZI MasterCard 

Account #_ ___ Exp. Date __ 

Signature _ _ _ 

Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 

5/91 

Name __________ 

Address_______ 

City State/Country _ Zip /Postal Code__ 


Please mail this order form to: USENIX Association 

2560 Ninth Street 
Suite 215 

Berkeley, CA 94710 

The proceedings are shipped within one week of publication. 


This offer is good through 
December 31,1991 


* Note: Corporate, Educational and Supporting Members of USENIX automatically receive a subscription to all 
proceedings published during their term of membership, which may overlap with this offer. 
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ORDER FORM 


OUT-OF-PRINT PROCEEDINGS 


The Association has photocopied, bound sets of the following past workshop and conference pro¬ 
ceedings. 


FOREIGN 


QTY 

CONFERENCE 


PRICE 

POSTAGE 

TOTAL 


San Francisco 

1988 Summer 

$29 

$20 

$ 


Dallas 

1988 Winter 

26 

15 

$ 


Phoenix 

1987 Summer 

35 

20 

$ 


Atlanta 

1986 Summer 

37 

20 

$ 


Denver 

1986 Winter 

25 

15 

$ 


Portland 

1985 Summer 

45 

25 

$ 


Dallas 

1985 Winter 

15 

10 

$ 


Salt Lake City 

1984 Summer 

29 

20 

$ 


Washington, D. C. 

1984 Winter 

25 

15 

$ 


Toronto 

1983 Summer 

32 

20 

$ 


San Diego 

1983 Winter 

28 

15 

$ 


WORKSHOP 






Systems Admin. Ill 

1989 Austin 

13 

13 

$_ 


Systems Admin. II 

1988 Monterey 

8 

5 

$ 


Systems Admin. I 

1987 Philadelphia 

4 

5 

$ 


UNIX Security 

1988 Portland 

7 

5 

$ 


Graphics III 

1986 Monterey 

10 

5 

$ 


Graphics II 

1985 Monterey 

7 

5 

$ 


Total price of Proceedings 
Calif, residents add 7% sales tax 
Total foreign postage 

* Discounts are available for bulk orders. Please inquire. Total enclosed 


PAYMENT OPTIONS 

D Check enclosed payable to USENIX Association. — 1 Purchase order enclosed. 
EH Please charge my: EH Visa EH MasterCard 


Account# 

Signature 


Exp.Date 


Outside the USA? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 


Shipping Information 


5/91 


Orders to U.S. and Canada are shipped via printed matter. Please allow 2-3 weeks for delivery. Foreign orders are 
shipped via air printed matter. 


Ship to: 


Please mail this order form to: USENIX Association 

Suite 215 

2560 Ninth Street 

Berkeley, CA 94710 


May/June 1991 
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ORDER FOR M 


CONFERENCE & WORKSHOP PROCEEDINGS 


Qty Proceedings 



Member 

Price 

Non-Member 

Price 

Total 

Foreign 

Postage 


June '91 

$32 

$38 

$ 

$22 

$_ 

Jan. '91 

28 

34 

$ 

18 

$_ 

June '90 

22 

same 

$ 

15 

$_ 

Jan. '90 

25 

ft 

$__ 

15 

$_ 

June '89 

20 

tt 

$ 

15 

$_ 

Feb. '89 

30 

tt 

$ 

20 

$_ 

Mar ’91 

30 

34 

$ 

20 

$_ 

Oct. '89 

30 

// 

$ 

20 

$_ 

Oct. '90 

17 

20 

$ 

9 

$_ 

Oct. '90 

15 

18 

$ 

8 

$_ 

Aug. ’90 

13 

16 

$_ 

8 

$_ 

Apr. '91 

22 

26 

$ 

11 

$_ 

Apr. '90 

28 

tt 

$. 

18 

$_ 

Oct. ’88 

30 

" 

$_ 

20 

$_ 

Nov. '87 

30 

// 

$ 

20 

$ 

Nov, '89 

18 

tt 

$_ 

10 

$_ 

May '89 

12 

ft 

$ _ 

8 

$_ 

Apr. 89 

20 

tt 

$_ 

15 

$_ 

Sept. '88 

20 

tt 

$_ 

10 

$_ 

Nov. '89 

18 

ft 

$ 

10 

$ 

Oct. ’87 

10 

" 

$ _ 

15 

$_ 

Jan. 87 

10 

tt 

$ 

20 

$_ 


Total 


Nashville Conference 
Dallas Conference 
Anaheim Conference 
Washington DC Conference 
Baltimore Conference 
San Diego Conference 
Distributed & Multiprocessor Sys. (SEDMS) II 
Distributed & Multiprocessor Sys. Workshop 
Mach Workshop 

Large Installation Sys. Admin. IV Conference 

UNIX Security II Workshop 

C++ Conference 

C++ Conference 

C++ Conference 

C++ Workshop 

Graphics Workshop V 

UNIX Transaction Processing Workshop 

Software Management Workshop 

UNIX and Supercomputers Workshop 

Graphics Workshop V 

Graphics Workshop IV 

Washington DC Conference 


v Discounts are available for bulk orders. Please inquire. 


PAYMENT OPTIONS 

□ Check enclosed payable to USENIX Association. □ Purchase order enclosed. 
Q Please charge my: O Visa Q MasterCard 


Total price of Proceedings _ 

Calif, residents add 7%sales tax _ 

Total foreign postage _ 

Total enclosed $_ 


Account # 


Signature 


_ Exp.Date 


Outside the USA? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 


Shipping Information 


5/91 


Orders to U.S. and Canada are shipped via printed matter. Please allow 2-3 weeks for delivery. Overseas orders are 
shipped via air printed matter. 


Ship to: 


Please mail this order form to: 


USENIX Association 
2560 Ninth Street 
Suite 215 

Berkeley, CA 94710 
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4.3BSD MANUAL REPRODUCTION AUTHORIZATION and 


ORDER FORM 


Date: 


Pursuant to the copyright notice as found on the rear of the cover page of the UNIX® /32V 
Programmer's Manual stating that: 

"Holders of a UNIX ®/32V software license are permitted to copy 
this document, or any portion of it, as necessary for licensed 
use of the software, provided this copyright notice and statement 
of permisssion are included," 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and 
provide me with such copies of the Berkeley 4.3BSD Manuals as I may request. 

Signature: ___ 

The prices below include shipping (via UPS) and handling charges for domestic and Canadian orders. 


4.3BSD User's Manual Set (3 vols) _at $28.00 each 

4.3BSD Programmer's Manual Set (3 vols) _at $28.00 each 

4.3BSD System Manager's Manual (1 vol.) _at $12.00 each 

Total 

Discounts are available for bulk orders. Please inquire. 


Overseas Postage only 

$_ $35. each 

$_ 35. each 

$_ 16. each OR 

$_ $62 for complete set 


PAYMENT OPTIONS 

CH Check enclosed payable to USENIX Association. Q Purchase order enclosed.* 
Q Please charge my: □ Visa □ MasterCard —mm 

Account # _ __Expiration Date 

Signature_ ___ _ 

* Outside the U.S.A.? Pre-payment is required in U. S. currency by one of the following: 

* Charge (VISA, MasterCard, or foreign equivalent) 

* International postal money order 

* Check -issued by a local branch of a U.S. Bank 


Ship to: __ ___ Bill to, if different: 


Phone: 


Mail your check or purchase order with this order form to: 
USENIX Association, Manual Order Dept. 

2560 Ninth Street, Ste. 215 
Berkeley, CA 94710 
415/528-8649 
FAX 415/548-5738 


PLEASE ALLOW 3 WEEKS FOR RECEIPT OF YOUR ORDER. 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


SECOND CLASS 
APPLICATION PENDING 
at Berkeley, CA and 
addititional offices 


Postmaster: Send address changes to USENIX Association, 2560 Ninth Street, Ste. 215, Berkeley, CA 94710. 


Book Review: perl 
Member Survey Results 
Mach Symposium 


Gene Spafford 
Purdue Univ. 

Software Eng. Research Center 
Dept, of Computer Sciences 
W. Lafayette, IN 47907-2004 
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